Rad jsem si precetl. Taky jsem odchovan barevnym borlandim debuggerem, no jeste taky basicem na SAPI, ale to uz je davno.
Betelny bylo, kdyz se debugger a sysman vesel na jednu 5 1/4 disketu. To jsem si uzil spoustu legrace, kdyz jsem na tatove pocitaci s odpojenym harddiskem zkoumal nove viry.
Ale 2 pripominky:
S tim efencem je to uuuuplne jinak. On neplni pamet pred a za alokovanym usekem smetim. To smeti tam potencianalne bude, pokud ho nepouzijeme.
On dava za nebo pred (podle promenne prostredi EF_PROTECT_BELOW) alokovavy blok neplatnou stranku, takze preteceni (podteceni) zpusobi pagefault.
A ta druha pripominka: nepsal bych "homu" ale "houmu" ;-)
Obvykle vznikají v důslekdu použití libtoolu, takže stačí namísto
gdb program [core]
spouštět
libtool gdb program [core]
přičemž program teď může být i ten wrapper.
Jinak jsem moc nepochopil, proč při spuštění gdb defaultně znovu spouštět ten program, když jsem nejspíš před chviličkou vyhrál v loterii pěkný coredump ... ale o tom asi bude příště. (Nj, nj, já vím, že podle návodu jsem ten článek neměl vůbec číst.)
Ad proc poustet: no treba proto, ze mam core dumpovani defaultne vypnute (maly plech z ulabu, kde je quota 10 mega, ackoli uz tam davno nesedavam) :). Kazdy ma jine zvyky, ja preferuji slitavani v gdb a core natahuju, jen kdyz se to v gdb chova jinak nez na vzduchu...
Jinak diky vsem za plodne pripominky, ja jsem precejenom jen takove male BFU (nebo deticko, chce-li nekdo :))
Je dobre, ze se do tohodle nekdo pustil. Mel bych jeste par poznamek:
1. pouzivat gdb je pekne pokud alespon tusite co hledat
2. musi byt mozne chybu vyvolat, bohuzel kazdy dobre vychovany bug se objevuje jednou za 1000 startu programu ve zcela tezko odhadnutelnem okamziku a podminek
3. v multi-thread programech pokud je bug "nekde mezi thready" muze byt pak hledani nocni murou.
Co to vse znamena? Psat program tak, aby debugger byla jedna z poslednich moznosti a pocitat dopredu s tim, ze budu delat chyby. Reseni je pridavat primo do programu vsude kde to ma smysl (treba parametry funkci) kontrolni rutiny a debugovaci hlasky o tom co program dela. Kouknete se treba na kod GTK a dalsich projektu na ruzna Assert() makra apod.
Nejlepsim debuggerem je ten co ho nemusime pouzit :-) A vzdy je lepsi pokud program nekde hapal tak udelat "vim muj.log" nez startovat gdb a snazit se o (nekdy nemozne) simulovani podminek, ktere buga odalaly.
>Nejlepsim debuggerem je ten co ho nemusime
>pouzit :-) A vzdy je lepsi pokud program nekde
>hapal tak udelat "vim muj.log" nez startovat gdb
>a snazit se o (nekdy nemozne) simulovani podminek, >ktere buga odalaly.
Musim vyjadrit nesouhlas. Resp. souhlas, az na jednu drobnost. NENI nad to, kdyz u slozite rutiny muzu postupne krokovat a kontrolovat si jesli je vsechno tak jak byt ma.
Lehce se stane, ze napisu neco, co 'produkuje' dobry vysledek, nicmene, je tam skryta chyba, ktera vypluje jindy.
Kdyz mam moznost si to project, tak mimo to, ze to clovek 'projde', ma jeden kontrolu nad tim, jesli to ve vsech castech dela to co dela... Na tohle jsou dobre ruzne 'nadstavby' gdb.
A logy zacinaji byt k nicemu, cim 'vice' toho program dela, aneb, hledejme chybu z logu, kdyz treba generuju video :)
Urcite je dobre pokud muzete krokovat. Problem je pokud nejste schopen si byt jist, ze tak jak se to chova pred vasima ocima se to bude chovat pokazde. Log je dobry tam kde to proste najednou bez zjevne priciny spadlo a neni mozne stejny pad simulovat snadno znova. V dobre delanem logu pak staci se podivat na konec a budete vedet co se deje (a muzete nasledne treba pouzit debuger). Jak jsem psal opravdove to dokaze proverit napriklad deset threadu a hledani nejakeho bugu "nekde tam uvnitr".
Netvrdim, ze pouzivani debuggru je spatne. Tvrdim, ze mit nekolik MB zdrojaku a nasledne spolehat pri hledani chyb jen na debugger je silenost.
O Johance nemuzu rict ani ze ji nenavidim, ale ani, ze ji miluju... Stejne jako o ostatnich autorech clanku na rootu.
Neni tahle zboznost trochu nefer vuci tem ostatnim? Copak je v clancich Johanky tak specialniho oproti tem ostatnim? Proc nikde jinde nevidim "XYZ, milujeme te"?
Posledni dobou mi pripada, ze kdo nezboznuje Johanku, jako by nebyl in. :-( Ja se vzdycky snazil byt spis out, takze pokud zacne hromadne milovani Johanky (ne to fyzicke :-) ), ja se budu muset bohuzel priklonit na druhou stranu... Sorry, Johanko... :-)
Vychadzajme z teorie, ze pri dvoch javoch A a B, cloveku robi jav A vacsiu radost ako jav B, ked sa jav A vyskytuje castejsie ako jav B. (Za predpokladu, ze Ti oba robia radost samozrejme.)
Clankov, kde Ti dakuju, mas na roote celkom dost, nie? Chces sa vyjadrit k presnym cislam relevantnym pre tuto teoriu?
<i>Neni tahle zboznost trochu nefer vuci tem ostatnim? Copak je v clancich Johanky tak specialniho oproti tem ostatnim? Proc nikde jinde nevidim "XYZ, milujeme te"?</i>
Myslim, ze to je jednoduche:
1. Je to zena. Mam pocit, ze mladsia alebo zhruba vo veku svojich citatelov.
2.Ma styl prejavu. Ci uz sa vam ten styl paci alebo nie, je irelevantne. Je to napadny styl. Ked citam iny clanok tak ma nenapadne: "to isto pisal XY". A tak nabuduce si clanok precitate len preto, ze je od Johanky.
3. To co pise, ma spravidla hlavu a patu. Evidentne vklada vela usilia na to aby prenikla do danej problematiky. Aktivne reaguje na komentare k clankom.
4. Vybera si zvlastne temy. Zoberie temu o ktore, vlastne moc na zaciatku nevie, ale vie, ze je to nieco, co kazdy pouziva. Prenikne do problematiky hlbsie a hlbsie a napise veci, ktore inych trapia, ale ti ini nie su ochotni tomu venovat tolko casu (alebo sa nemaju koho spytat,pravda).
Takze, ak bude root-e aj iny autor, ktory splna tieto body, isto sa aj on docka svojich vyznavacov.
Nepovažuju se sice za BFU, ale práce v GDB je podle mě maximální masochizmus. Když jednou za čas debugger potřebuju, nechci trávit několik dní s konfigurováním a studováním "jak to vlastně pracuje". Takže pokud jste na tom někdo obdobně jako já, doporučuji frontend DDD (Data Display Debugger) http://www.gnu.org/software/ddd/.
Běží to v GTK a má to obdobná "okna" jak zmiňovaný Pascalí debugger a vůbec to celé vypadá tak nějak přívětivě. A GDB konzole je tam taky... :)
Nemyslim si ze gdb je pro masochisty je to skvely tool jen to chce se naucit par zakladnich prikazu, pak je to velice silny a efektivni nastroj, sice jak zde nekdo psal multiproces,multithreaded asynchroni aplikace se s tim ladi hodne spatne ale i to s trochou trpelivosti jde ...GDB rulez ....
Pokud má někdo konstruktivní připomínky (či dokonce patche) k jednomu z těchto skriptů (gdbvim), budou vítány i v češtině ;-).
Hlavním problémem tohoto scriptu, jak to vidím já, je to, že neumí (a asi umět nebude) doplňování ála readline v gdb. Což mně osobně až tolik nevadí vzhledem k možnostem vimu.
Kromě uvedených projektů ještě existuje projekt aap (originál od Brama) http://www.a-a-p.org, který nabízí totéž jako svoji součást (agide). Docela by mne zajímalo, jestli s ním má někdo zkušenosti (mně to přišlo jako trochu overkill pro úlohu debugování pod vimem).
Cely problem spociva v tom, ze clovek, ktery gdb potrebuje jednou za mesic/pul roku/milenium/... mezitim zapomene, jak se to cele ovlada :). Pak neni spatne mit po ruce sikovny frontend, ktery mu umozni si to nepamatovat. Ten muze byt ostatne prijemny na pouzivani i zkusenejsimu uzivateli, ne ?
:-) take mne vychoval borland (barvy jsem si vzdycky upravil jinak, takze nevim o jake modre Johanka pise ;) Svoje programy ladim temer zasadne v GDB-mode emacsu od 'prikazoveho radku' gdb se to lisi jen minimalne, ale je pohodlne v jedne casti okna sledovat gdb a v druhe koukat na aktualni kod. Cili: GDB in Emacs rules!
Když jsem se naposledy díval, DDD nejelo pod Gtk+, ale [open]motifem ;-)
Jinak DDD je pěkné, občas ho používám, když vím, že budu debugovat dlouho a se spoustou watchů... OTOH tak v 30% případů mi stačí spustit
gdb program core
bt
l
abych věděl, na čem jsem, což je v DDD o dost pomalejší, i když je spuštěné pořád a jen reloaduji. A DDD nespustíte v putty.
Neni to spatny, ale neslo by to bez toho zvatlani ?
Kuprikladu nechapu, proc by mel byt za BFU povazovan nekdo, kdo pouzije debugger s nejakou "grafickou" nadstavbou...
Mne surove gdb nevadi, ale kdysi (10-12 let to je) jsem velmi intenzivne ladil v TurboDebuggeru od Borlandu veci, ktere jsem delal pod DOSem v Assembleru. Ten TurboDebugger mne velice vyhovoval a nemyslim si, ze bych byl BFU...
Tato poznamka mi prijde jako typicka ukazka americke vychovy k politically correct zivotnimu nazoru. Ja uz jenom cekam, kdy se treba plesatym zacne i u nas rikat "vlasove postizeny" (hair impaired) nebo misto vystizneho blbec ponekud neosobni "osoba mentalne specificky obdarena".
Nevim proc mam ten dojem, ale kolem komunity linuxaru se nemuzu zbavit pocitu neustalyho a hlavne nesmyslnyho machrovani jednoho na ostatni ve stylu:
ty ses ten looser co si klika, zatimco ja guru funguju v prikazovy radce a brzo budu umet nazpamet uz 1000 klavesovejch zkratek ve vimu nebo emacsu a psat skripty sem umel este driv nez sem chodil do skoly.
Spousta lidi mi vypravela o tom, jak je gdb uzasnej tool, ale musim se pousmat: zkusil nekdo z tech co tohle tvrdi alespon jednou debuger NuMega SoftIce (pod Wokna) jestli jo, tak myslim, ze to zcela resi odpoved na otazku jak ma vypadat naprosto dokonalej debugger, a nic podobnyho bohuzel na linuxu neznam, a je mi to opravdu lito. A opravdu si nemyslim, ze jsem BFU, zkuste napriklat nekdo napsat crack na nejakou aplikaci v gdb (hodne stesti) - pod SIce to je otazka minut. ;-)
No, tak trochu jsem si hral s protokolem pro remote target a psanim gdbstubu. A chvilema jsem byl docela rad, ze gdb proste funguje a ja nemusim nijak moc premyslet o tom proc a jak.
Jinak i dostupna dokumentace o vnitrnim fungovani gdb je pomerne strusna a misty nedodelana.
Ale clanky 'Implementace prikazu 'c' snadno a ryche', popripade 'Hledame addresu nasledujici instrukce a jine bajky' by se tenkrat hodily.
Nemusis mit zadne trauma. Me se tvuj styl psani libi. Je videt, ze tomu rozumis a navis si tak srandovni. Nemam rad, kdyz se autori snazi sve nedostatky zahnat popularizovanim a vtipky. Ale ty nejses ten pripad. A pokud se to nejakemu zastydlemu linuxakovi nelibi, tak vis co ti muze :). Posilam ti pusu za kvalitni a pekny clanek. Jestli te to teda neurazi :)
IMHO: GDB (A JAKYKOLIV DB) JE TAKOVY KAZDODENNI SVATEK POJIDACU KOLACU. COZPAK NEVITE, ZE OPRAVDOVI PROGRAMATORI ZADNY DEBUGGER NEPOUZIVAJI A VSECHNY CHYBY NALEZNOU V OKTALOVEM "POSTMORTU" Z TABELACNI TISKARNY?
JAK VZDYCKY RIKAVAL JEDEN MUJ DAVNY KOLEGA: "PROBLEM DEBUGGERU NENI V TOM, ZE BY NEPOSKYTOVAL POTREBNE INFORMACE, ALE V TOM, ZE UZIVATELE ZAHLTI NEPOTREBNYMI INFORMACEMI A V NICH MU UKRYE TO CO HLEDA". NAVIC OPRAVDOVY PROGRAMATOR POUZIVA ZAPORNYCH INDEXU POLI KE ZMENAM V OPERACNIM SYSTEMU A TO JE V DEBUGGERU NELADITELNE!
P.S.: PO PRECTENI KOMENTARU ZJISTUJU, ZE MEL PRAVDU (BOHUZEL).
Hmmm, to pak ten kod musi byt hodne dobre portabilni, kdyz se v nem pouzivaji zaporne indexy poli ke zmenam v operacnim systemu. Takhle se dalo programovat pod CP/M a jeste pod DOSem, pak prisly systemy bezici v protected modu a kdyz jsem tehdy par svych zdrojaku skompiloval v Borland C++ for OS/2, tak jsem se nestacil divit, proc mi system ten program furt shazuje na obdobach "Segmentation fault". Tehdy jsem si uvedomil, ze je lepsi psat kod ciste a od te doby se mi to vyplaci.
Jsem zvedavy, co bude dal. Povazoval jsem se za skupinu c.2, ale nedozvedel jsem se prakticky nic vic, nez ze existuje prikaz backtrace, ktery je to jedine, co z gdb znam :-)
(koneckoncu je o nem zminka prakticky u kazdeho opensource softu, kde se autor snazi primet siroke uzivatelstvo k pricetnym bugreportum).
Clanky DJky Dolezalove me vzdy vedou k dilematu zda cist a dovedet se neco o zajimavem tematu nebo necist a nepozastavovat se nad osobitym stylem. Musim rict, ze jsem mel asi dobrou naladu, protoze tento clanek mi prisel normalni.
No ale spise jsem se chtel pozastavit nad hojnym pouzivanim pofidernich zkratek v diskuzi. Evidentne "vysla" do mody nova OTOH. Jasne, chapu, ze to nejde rict cesky. Pridavam si ji do seznamu (jeste ze nas Buh obdaril tim googlem): IMHO, ASAP, AFAIK, AFAIS, OTOH. Vam se to libi?
Toz tak. Jo, to BFU jsem taky nevedel, ale urcite bych se tak nenazyval, jeste bych se mohl urazit.
Mam problem. Mam program (zdroj asi 0.5MB). (Kdyby Vas to zajimalo tak je to na simulace plazmatu.) Problem je v tom, ze tam mam segmentation fault, ktery se projevuje, resp. pada, uplne nahodne. Zkousel jsem vypisovat zacatky a konce volanych funkci, abych odhadl, kde to pada. Pada to pokazde nekde jinde. gdb je tak strasne pomalej, ze nemam sanci. Prosim help.