gdb: corrupt stack? wie debuggen?

[7.e.Q]

Hallo,

ich habe einen Absturz in meiner Software, den ich mit gdb offenbar nicht korrekt debuggen kann. Trotz vorhandener Debug-Informationen erhalte ich nur Fragezeichen statt der nötigen Informationen. Es steht mir keinerlei Information über die Herkunft des Absturzes zur Verfügung. Nichts. Nur wirre Stack Adressen und Fragezeichen. Als hätte die Software keine Debug-Informationen. Gebe ich bt ein, erhalte ich bis zu 200 Frames angezeigt und am Schluss der Liste die Fehlermeldung "Previous frame inner to this frame (corrupt stack?)".

Wie kann man eine solche Software debuggen, und wo kommt dieser Fehler her? Was kann ihn theoretisch auslösen?

Danke

Gruß,
Hendrik

[RapidMax]

Das könnte daran liegen, dass dein Programm durch einen Buffer-Overflow den Stack überschreibt. Wenn du keine Lust hast, von Anfang an bis zu der Stelle zu debuggen, dann könnte dir die Stack Smashing Protection (http://en.wikipedia.org/wiki/Stack-smashing_protection) von gcc helfen. Sobald das überschriebene canary entdeckt wird, bricht dir das Programm mit dem Namen der fraglichen Funktion ab.

Gruss, Andy

[7.e.Q]

Hi,

ich werd das mal testen. Danke! :)

edit: hmm... tja... also den StackGuard scheint es nur für den 2er GCC zu geben und ProPolice scheinbar auch nur für den 3.3.2er als Patch. Ich hab aber den 3.3.3er GCC. Was mach ich nu?

Außerdem darf ich mir das System nicht verhunzen. Wenn da was mit dem GCC schief geht, dann bin ich aufgeschmissen. Es handelt sich dabei nämlich um ein LFS. Ich könnte natürlich vorher 'n Backup machen...

Gibt es nicht irgendwelche anderen Möglichkeiten, Programme, Debugging Tools für Linux, mit denen man Buffer Overflows überwachen kann?

edit: okay, ich versuch das mal, wie das bei ProPolice auf der Homepage steht. Mal sehen. System bootstrap't gerade.

[Joghurt]

Evtl. kann valgrind das. Ist auf jeden Fall sehr, sehr nützlich, um Speicherlecks zu finden.
http://valgrind.kde.org

[7.e.Q]

Oh, richtig. Valgrind kann man dafür ja auch nutzen. Merkwürdig finde ich allerdings, daß mit dem selben Code (kleine Anpassungen wegen der Syntax) und dem neuen 3.4er GCC das Programm nicht mehr abstürzt.

Mein Programm stürzte teilweise auch in der basic_string Klasse ab, wenn ich auf die Funktion c_str() Zugriff genommen habe. Ganz merkwürdig. Das tritt seit dem Wechsel zum GCC 3.4.1 nicht mehr auf.

Mal sehen, ob mir der neue GCC jetzt zu einem stabileren Programm verhilft. :)