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
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.
Lehet régi gdb-t használok, nekem nincsenek ilyen fancy @entry értékeim :) ezert kellene latni a kodot (vagy legalábbis a fgv definiciokat), mert ez alapjan a _pelda1 ket bar arg-al is rendelkezik ami nehezen hiheto
// Happy debugging, suckers
#define true (rand() > 10)
Az efl-ről van szó. A teljes gdb kimenet. Nem kis kódbázis, meg speciális eset, mert NetBSD-n jön elő, linuxon működik.
Ahh, oke, melyik verzió belőle? A master-en a sorok nem oda esnek ahova kellene, bár itt nem is láttam olyat ami problémát okozna
// Happy debugging, suckers
#define true (rand() > 10)
1.24.3 az utolsó stabil release
Mivel linux-on jó, ezért gondolom valami NetBSD érzékeny dolog, csak nem tudom melyik függvényben keressem, hol induljak. Na, nem mintha sok esélyem volna amúgy.. 😅
á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 :-)
meg lehet vadaszgatni a forditasi parametereket, optimalizacios kapcsolokat, es egyeb csodakat :)
Köszönöm a tippeket és hogy foglalkoztatok vele.
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.
Köszi, megnézem valgrind-el is.