In meiner Anwendung handle ich mit SIGSEG, um ein Backtrace zu erzeugen, und rufe abort() an, um einen Core Dump zu generieren.Wie zu finden, welcher Thread SEGFAULT in einer post-mortem gdb Sitzung verursacht hat?
Wenn ich jetzt eine gdb-Post-Mortem-Analyse des Kerns ausführen, ist der Thread, der das SEGFAULT verursachte, nicht mehr sichtbar. Gibt es etwas, was ich tun kann, sehe ich die Ursache für die SEGFAULT?
Mit freundlichen Grüßen, Martin
können Sie Befehl thread apply all bt oder thread apply all bt full Backtraces aller Threads zu bekommen. Könnte nützlich sein.
Übrigens, wenn Sie Ihren Handler loswerden, wird Ihr Betriebssystem eine Kerndatei erstellen?
Momentan verwende ich den Handler, um ein Backtrace in stderr zu schreiben, also habe ich alles, da ich nichts aus der Core-Datei herausholen konnte. Ich muss versuchen, ob der Standard-Handler "bessere" Core Dumps erzeugt. –
'ulimit -c unlimited' und sehen Sie, welchen Kern Sie ohne einen Handler erhalten. –
@skwllsp, gibt es eine Möglichkeit, genau zu wissen, welcher Thread die SIGSEGV verursacht hat? Meintest du, dass es eigentlich nicht möglich ist, es zu wissen und die Rückseitenspuren verwendet werden müssen, um es zu finden? – russoue
Machst du auch andere Arbeit im Handler? Warum lässt du das Betriebssystem nicht einfach so laufen, dass es einen Core für dich übrig lässt? –
Erstellen Sie einfach einen Rückstand zu stderr und rufen Sie dann abort(). –
Bitte geben Sie Ihr Betriebssystem und was genau Sie in GDB beobachten. Unter Linux (und jedem anderen UNIX, das ich mir vorstellen kann) wird der SIGSEGV-Handler in dem Thread ausgeführt, der SIGSEGV an erster Stelle verursacht hat. Wenn dieser Handler abort() aufruft, enthält der Core-Dump diesen Thread als Thread # 1, und es wird kein Problem geben, genau herauszufinden, welcher Befehl und welcher Call-Stack das Problem verursacht hat. Da Sie Schwierigkeiten haben, sind Sie entweder auf einem "seltsamen" Betriebssystem oder Sie beschreiben nicht richtig, was Sie tatsächlich beobachten. –