Verwirrender Absturz

[7.e.Q]

Hi Leute,

wie kommen solche Abstürze (Segmentation Fault) zustande:



.
.
.
#772 0x30202029 in ?? ()
#773 0x6630302e in ?? ()
#774 0x54207370 in ?? ()
#775 0x3a6d6572 in ?? ()
#776 0x30202020 in ?? ()
#777 0x206e696d in ?? ()
#778 0x6d392020 in ?? ()
#779 0x41202062 in ?? ()
#780 0x303a562d in ?? ()
#781 0x3030302e in ?? ()
#782 0x31395b20 in ?? ()
#783 0x303a3431 in ?? ()
#784 0x00000d5d in ?? ()
#785 0x00000000 in ?? ()
(gdb)
(gdb)


Wie kann ich sowas debuggen? Das Programm enthält definitiv Debug-Infos, schmeißt aber keinerlei Informationen raus, wodurch dieser Absturz verursacht wurde.

Ich weiß nicht weiter, helft bitte!

Danke

Grüße,
Hendrik

[bischi]

Etwas mehr Infos...

1) Hast du den Quellcode?
2) Was für ein Programm?
3) OS?
4) Sprache?
5) Spezielle Umstände?

MfG Bischi

[7.e.Q]

1) ja
2) Selbstentwickelte "Eierlegewollmilchsau"
3) Linux From Scratch
4) C++
5) Es kommen auf einem Terminal per IPC viele Daten rein

Riecht ein bissl nach Buffer Overflow oder?

[bischi]

Riecht ein bissl nach Buffer Overflow oder?

Ne - ich denke mal, du versuchst auf irgendwelchen Speicher zuzugreifen, auf den du nicht darfst, worauf das OS dein Programm abmurkst (falschen Pointer,...).

Du könnstest jetzt nen Debugger nehmen oder ganz einfach an den Stellen, die dir kritisch erscheinen, ne Ausgabe machen...

MfG Bischi

[RapidMax]

Der Backtrace wird anhand der Rücksprung-Adressen auf dem Stack gebildet. Wenn du nun "sauber" einen grösseren Teil des Stack überschreibst (z.B. durch ein Buffer-Overflow), dann überschreibst du damit diese Rücksprung-Adressen. GDB weist anhand der Rücksprungadressen die Funktionsnamen zu, bei überschriebenen Adressen ist diese Zuordnung natürlich nicht möglich, so dass GDB nur ?? anzeigt. Mehr noch: Da die Struktur des Stack korrupt ist, werden von GDB fälschlicherweise sehr viele solche Einträge angezeigt, was nichts mit der wirklichen Function-Call Tiefe zu tun hat.

In diesem Fall hilft der Backtrace also nichts.

Ich empfehle stattdessen ein Debugger für Arme:

#define WHERE_AM_I() \
fprintf(stderr, "HERE %s:%d (%s)", __FILE__, __LINE__, __FUNCTION__)

Diese Zeile an den Anfang der Funktionen im Verdächtigen Teil des Code anhängen und stderr in ein Logfile umleiten, dann siehst du wo der Code abgebrochen wird. Nun kannst du kurz vor dieser Stelle ein abort() in den Code einfügen, und du erhälst ein core-Dump, sofern die Erstellung solcher erlaubt wurde (man setrlimit). Diesen kannst du nun mit gdb untersuchen und solltest durch die Untersuchung des Zustandes herausfinden können, an was es liegt. Gerade bei Speicherzugriffsfehler kann es aber auch gut sein, dass die eigentliche Ursache viel früher stattgefunden hat.

Gruss, Andy

[locus vivendi]

Valgrind oder die "mudflap" Option des GCC helfen vielleicht weiter.

[RapidMax]

Valgrind oder die "mudflap" Option des GCC helfen vielleicht weiter.
Stimmt, das ist natürlich die Komfort-Variante :)

Gruss, Andy

[7.e.Q]

mudflap funktioniert bei mir gar nicht. Der GCC sagt was von unrecognized option oder so.

[Joghurt]

Hast du "-mudflap" oder (das korrekte) "-fmudflap" geschrieben?

[7.e.Q]

-fmudflap ... hab ja extra in die Manpage geschaut. Geht nicht. :o