Vlákno názorů k článku Gdb pro normální lidi od Karel Zak - Je dobre, ze se do tohodle nekdo pustil....

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.

Mel jsem logy rad, dokud mi program nezacal generovat 3MB logu za minutu. Holt, 3D realtimove aplikace, co potrebuji logovat prilis mnoho veci v hlavni smycce a tu chteji provadet 100x za sekundu...

Log je dost dobra vec, ale tady uz narazi na dalsi problemy.

Logovanie moze sposobit aj jednu malu neprijemnost pri ladeni, ze spomali beh programu. A ta chyba, ktora sa pred vypnutym logovanim objavila vzdy sa neobjavi uz nikdy. Ale casto ju neodhali ani debuger.

nepsat 3d realtimove aplikace, kdyz jeste neumim
debugovat. pripadne faze2: logovat to co potrebuju
k debugu a pripadne to delat binarne.
faze tri nepsat do clanku pro zacatecniky, ze pisu
3d realtimove aplikace, kdyz jsem jeste navic jouda.

To je teda opruz. Predevsim 1 a 2 rada od Vas je mi teda uplne na nic.

Pro autora: dobry clanek