gdb kezdő

Fórumok

Van egy c,c++ alkalmazás, ami segfault-ol.

A gdb backtrace ehhez hasonlót ad vissza:

#0 _pelda2 (foo=foo@entry=0x4000000002ac, bar=bar@entry=0x0) at ...
#1 _pelda1 (foo=foo@entry=0x4000000002ac, bar=0x0, bar@entry=0x7ea57e10c4a8, baz=baz@entry=0) at ...
#2 _pelda0 (foo=foo@entry=0x4000000002ac, bar=bar@entry=0x7ea57e10c4a8) at ...

A kérdésem, hogy frame 1-ben a bar=0x0, bar@entry=0x7ea57e10c4a8, mit jelent?

_pelda1 úgy indul, hogy a bar még 0x7ea57e10c4a8, de benne 0x0 lesz, tehát a hibát a _pelda1-ben kell keresni, vagy _pelda0-ban már megváltozik bar és azzal hívja _pelda1-et?

Hozzászólások

Szerkesztve: 2020. 09. 22., k – 15:29

a backtrace-nél gyakorlatban a "call stack"-et látod, illetve a stack-en átadott paramétereket. Szóval jól sejted, ha a _pelda0 paraméterében még helyes a bar, viszont a _pelda1 paraméterében már nem (amit a _pelda0 hívott), akkor a _pelda0 valahol a hívás előtt agyonverte azt az értéket (vagy direktben 0x0 -val hívta).

De ez a kód ismerete nélkül csak feltételezés, lehet, hogy a _pelda0 a _pelda1 -et direktben 0x0 -val hívta meg, azt hogy honnan jött az az érték, az itt nem látszik csak a kódból

// Happy debugging, suckers
#define true (rand() > 10)

Csak azt nem értem mi az a bar@entry paraméter a _pelda1-nél, ami egyébként jó lenne. Azt olvastam, hogy a @entry az a függvény indulásakor valós érték, ezért nem értem hogy akkor _pelda1 jó paraméterrel indul és benne történik valami a bar-ral, vagy tévúton vagyok és már eleve rossz bar-t kap _pelda0-tól. 

átnéztem a kódot, a probléma kialakulásának környékén nem volt olyan ami problémát okozhat, mivel itt van egy while ciklusos rész, én arra tippelnék hogy már a többedik iterációban valami a mélyén cseszi el a stack-et.

Ez utóbbit viszont ennyiből már nem lehet kidebugolni, a kérdéses részt lépésről lépésre kell figyelni, nézni az állapotokat és egyre mélyebbre nézni, hogy hol és mi írja felül a stacket

// Happy debugging, suckers
#define true (rand() > 10)

Simán lehet túlcímzés, nullázatlan paraméter, stb. Bármi, ami egy C programot meg tud fektetni. Ha egyik rendszeren jó, a másikon nem, akkor ez a legvalószínűbb, illetve ha a típusok nem teljesen ugyanakkorák, akkor amiatti hibára is lehet tippelni. Vagy akármi másra :-)

Nem olyan egyszerű a hiba, mint elsőre tűnik. Valóban az efl-nél látszik hol romlik el a stack, és kap 0x0 értéket a pd paraméter amikor látszólag semmi sem változtatja meg. Ezt jelzi az @entry, hogy az előző híváshoz képest megváltozott az értéke. Viszont az _ecore_main_loop_iterate_internal() nagyon sok callback funkciót hív meg, az egyikben lehet hibás kód. Ezeket nagyon nehéz a gdb-vel végigkövetni. Erre a valgrind való, kiválóan végig tudja követni a stack változásait, és fel tud ismerni nagyon sok korrupciós hibát.