vaativa debuggaus linuxissa

Vaativa debuggaus linuxissa

Jotkut debuggaustehtävät ovat onneksi helpohkoja.

Mutta silloin tällöin valitettavasti törmää tilanteisiin, joissa haluaisi parhaan mahdollisen debuggerin käyttöönsä.

Ne, jotka tuntevat linux/gnu -käyttöjärjestelmän rakennetta tarkemmin, varmaan tietävätkin, että xwindow/GUI on linux -kokonaisuuden heikoin lenkki, ja monet palvelintehtävissä toimivat linuxkoneet toimivatkin täysin ilman asennettua xwindow/GUI -järjestelmää.

Mutta, entä, kun debugattava kohde on esim. videoplayeri? Videoplayerit tyypillisesti vaativat xwindow/GUI -ympäristön.

Vidoplayerinkin voi varmasti toteuttaa monella tavalla. Itse kokeilin ottaa xine:n kotisivulta löytyvän esimerkkikoodin (koodattu C:llä) ja muuntaa sen ohjelmasta .so -kirjastoksi, jotta voin koodata muun osan ohjelmasta haluamallani välineellä, tässä tapauksessa freepascal lazarus.

Valitettavasti tästä seuraa tiettyjä ongelmia:

xwindow on suunniteltu niin, että yleensä 1 sovellus voi käpistellä GUI -liittymää vain yhdestä säikeestä.

Silti sekä xine -moottorilla että tyypillisellä fp/lazarus GUI -ohjelmalla on oma viestisilmukkansa.

Siispä joko:

a) kumpikin täytyy laittaa omaan säikeeseensä

tai

b) nuo 2 silmukkaa täytyisi jotenkin pystyä integroimaan yhdeksi, joka hoitaa molempien aiemmat tehtävät.

tuolla a -ratkaisulla saa helposti koko window/GUI -järjestelmän niin jumiin, että kernel on ainoa, mikä säilyy toimintakelpoisena, koko muu osa linux -järjestelmästä on jumissa.

Pahimmillaan vielä jumiutunut prosessi rohmuaa 100% CPU -ajasta, jolloin etäkirjautuminen ssh:lla toimii, mutta sisäänkirjautuminen saattaa kestää 5 minuuttia, kun ryöstäytynyt prosessi rohmuaa itselleen lähes 100% (ehkä "vain" 99,99%) CPU -ajasta !

Ja etäkirjautumisen jälkeen 1. temppu on su -komento, sillä pääkäytttäjänä on ainakin oikeudet asettaa ongelmaprosessin nice level mahdollisimman korkeaksi (niin, korkea nice -level = alhainen prioriteetti).

Ongelmatapausten hoitamiseen siis tarvittaisiin mahdollisimman pureva debuggeri.

gdb:n "etädebuggaus" toimii juuri päinvastoin kuin tässä olisi tarpeen, gdb:n etädebuggaus kun soveltuu lähinnä siihen, että linuxkone tarjoaa debuggerin käyttöliittymän, ja esim. usb -kaapelilla kiinni oleva sulautetun prosessorin (ns. mikrokontrolleri) kokeilukortilla ajetaan debugattavaa ohjelmaa.

Siispä pitäisi toteuttaa oma debuggeri.

Jotta siitä saataisiin mahdollisimman pureva myös ongelmatapauksiin, niin kysyisinkin seuraavaa:

Kun linuxkoneella, jolla pyörii GUI (xwindow) halutaan käynnistää vaikkapa ./ohjelma

jossa tuo ohjelma siis on GUI -moodin ohjelma.

Ja toisaalta halutaan, että debuggeri säilyy toimintakelpoisena, vaikka koneen xwindow/GUI menisi täysin jumiin, niin mahdollisuuksia ei ole monta.

Mutta tässä 1, mikä saattaisi toimia:

1. siirrytään vaikkapa virtuaalikonsoliin 3 (Ctrl-Alt-F3)

2. kirjaudutaan sisään samalla käyttäjätunnuksella, jolla GUI -tilassa ollaan kirjautuneena, ja siirrytään hakemistoon, jossa tuo "ohjelma" sijaitsee

3. komennetaan:
omadebuggeri -debuggerinparametri ./ohjelma -ohjelmanparametri

3b. Mitä parametreja pitää antaa ja mihin, jotta debuggeri käynnistyy tekstipohjaisessa virtuaalikonsolissa 3, mutta ohjelma (debuggerin alaisuudessa) käynnistyy GUI -screenille (eli siis sille, mihin useimmissa linuxjakeluissa pääsee Ctrl-Alt-F7, paitsi esim. Knoppixissa Ctrl-Alt-F5) ?


4. debuggerin palvelinosa käynnistyy virtuaalikonsolissa 3 ja ohjelma käynnistyy (tai ainakin latautuu) GUI -screenille

5. eri koneella avataan oman debuggerin GUI -osa (oma debuggeri on siis rakennettu 2 -osaiseksi, palvelinosa joka toimii tekstitilassa ja GUI -osa, joka toimii xwindow GUI -sovelluksena, ja nämä debuggerin 2 osaa keskustelevat keskenään TCP/IP:llä jolloin ne voi ajaa eri koneella) ja otetaan sillä yhteys debuggerin palvelinosaan

6. debuggerin palvelinosa tulostaa virtuaalikonsoliin 3 teksitiedotteen "debuggerin GUI -osan yhteydenotto osoitteesta 192.168.0.251 on hyväksytty; debuggerin ohjaus ko. koneelta on käyttövaslmis" ja GUI -osa näyttää vastaavan dialogboxin tuolla .251 -koneella.

7. Virtuaalikonsolista 3 siirrytään takaisin GUI -tilaan Ctrl-Alt-F7 tai vastaava.

8. omaa debuggeria voi nyt ohjata eri koneelta, joten jos ja kun debugattavassa koneessa xwindow jumiutuu, niin eikö virtuaalikonsolilta tekstitilassa käynnistetty debuggeri pitäisi olla turvassa xwindowin kaatumiselta ja säilyä toimintakuntoisena, ja siihen toiseen koneeseenhan ei ykköskoneen xwindowin kaatuminen pitäisi mitään vaikuttaa.

Onko siis olemassa keinoa, jolla tekstimuotoisesta virtuaalikonsolista käynnistetty ohjelma voisi käynnistää toisen ohjelman saman koneen GUI -screenille ?

Jos, niin miten tuon saa aikaiseksi ?

Ja vielä: Jos rakennan oman debuggerini niin, ettei se tarvitse gdb:tä avukseen, niin miten on kernelin debug -toiminnallisuuden kanssa: onko kyseessä ns. vakaa API, jolloin funktiokutsun parametrit (kerneliä kutsuttaessahan nuo parametrit laitetaan cpu:n rekistereihin ja ainakin 80x86 -prosessoreissa seuraava temppu on int 80h, joka toteuttaa kernel -kutsun omasta ohjelmasta käsin) pysyvät kernelin versiosta toiseen samana, vai saanko kiusakseni sen, että aina kun kernelistä tulee uusi versio, niin joudun muuttamaan ohjelmaani sen osalta, mitä kernel -kutsuja ohjelma tekee debugattavan ohjelman kontrolloimiseksi ja mitä parametreja nuo kutsut tarvitsevat ?