segfault nur, wenn KEIN Debugger verwendet wird

Lesezeit: 3 Minuten

Ich habe ein Multithread-C-Programm, das an einem bestimmten Punkt im Programm ständig einen Segmentierungsfehler generiert. Wenn ich es mit gdb starte, wird kein Fehler angezeigt. Können Sie sich einen Grund vorstellen, warum der Fehler möglicherweise nur auftritt, wenn Sie den Debugger nicht verwenden? Es ist ziemlich ärgerlich, es nicht verwenden zu können, um das Problem zu finden!

  • Diese Art von Bug heißt “Heisenkäfer” und kann viele Ursachen haben.

    – Sven Marnach

    7. Januar 2011 um 17:47 Uhr

  • Hängt der Fehler zufällig mit der Fensterverwaltung und/oder der User32.dll zusammen?

    – Benutzer541686

    7. Januar 2011 um 17:48 Uhr

  • Ich hatte ein Problem wie dieses, mein Programm stürzte nur mit GDB ab. Das Problem war, dass eine nicht initialisierte Klassenmitgliedsvariable immer noch den Wert 0 erhielt, als ich mein Programm ausführte, aber als ich es in GDB ausführte, hatte es einen riesigen Wert, der segfaulted, als ich es als Array-Index verwendete.

    – GWW

    7. Januar 2011 um 17:50 Uhr

  • Nicht Windows-bezogen – Ich verwende Linux 2.6.32-24-generic #43-Ubuntu.

    – Benuvogel

    7. Januar 2011 um 17:53 Uhr

  • Haben Sie versucht, einen Core-Dump zu arrangieren? Laufen ulimit -c unlimited bevor Sie das Programm außerhalb des Debuggers starten, dann gdb myprogram core nachdem es den Kern entleert hat. gdb wird dann in der Lage sein, Ihren Segfault post mortem zu posten.

    – Robie Basak

    7. Januar 2011 um 18:03 Uhr

Benutzeravatar von user541686
Benutzer541686

Klassisch Heisenbug. Aus Wikipedia:

Zeit kann auch ein Faktor bei Heisenbugs sein. Das Ausführen eines Programms unter der Steuerung eines Debuggers kann die Ausführungszeit des Programms im Vergleich zur normalen Ausführung ändern. Zeitkritische Fehler wie Race-Conditions werden möglicherweise nicht reproduziert, wenn das Programm durch Einzelschritt-Quellzeilen im Debugger verlangsamt wird. Dies gilt insbesondere, wenn das Verhalten eine Interaktion mit einer Entität umfasst, die nicht unter der Kontrolle eines Debuggers steht, wie beispielsweise beim Debuggen der Netzwerkpaketverarbeitung zwischen zwei Computern und nur einer unter der Kontrolle des Debuggers steht.

Der Debugger ändert möglicherweise das Timing und versteckt eine Racebedingung.

Unter Linux deaktiviert GDB auch die Adressraum-Randomisierung, und Ihr Absturz kann spezifisch für das Adressraum-Layout sein. Versuchen (gdb) set disable-randomization off.

Endlich, ulimit -c unlimited und Post-Mortem-Debugging (bereits von Robie vorgeschlagen) könnte funktionieren.

  • ‘set disable-randomization off’ hat ein ähnliches Problem für mich gelöst!

    – Marcus Johansson

    30. Juni 2014 um 7:30 Uhr

Vielleicht bei der Nutzung gdb Der Speicher wird an einem Ort abgebildet, an dem Ihr Über-/Unterfluss nicht auf dem Speicher herumtrampelt, der einen Absturz verursacht. Oder es könnte eine Rennbedingung sein, die nicht mehr ausgelöst wird. Obwohl es nicht intuitiv klingt, sollten Sie es sein glücklich Ihr Programm war nett genug, um bei Ihnen abzustürzen.

Einige Vorschläge

  1. Probieren Sie einen statischen Codeanalysator wie den kostenlosen aus
    cppcheck
  2. Versuchen Sie einen malloc()-Debugger wie
    libefence
  3. Versuchen Sie, es durchzuspielen Valgrind

Durch das Debuggen ändern Sie die Umgebung, in der es ausgeführt wird. Es hört sich so an, als hätten Sie es mit einer Art Race-Condition zu tun, und durch das Debuggen werden die Dinge etwas anders geplant, sodass Sie nicht auf das Problem stoßen. Das, oder die Dinge werden etwas anders gespeichert, damit es nicht passiert. Können Sie einige Debugging-Ausgaben in den Code einfügen, um das Problem zu lösen? Dies hat möglicherweise weniger Auswirkungen und ermöglicht es Ihnen, Ihr Problem zu finden.

Ich hatte dieses Problem schon einmal! Es war eine Race-Bedingung, und als ich den Code mit einem Debugger durchschritt, war der Thread, in dem ich mich befand, langsam genug, um die Race-Bedingung nicht auszulösen. Ziemlich furchtbar.

Wenn Sie verwenden gccversuchen Sie es mit der -Wall Option, um alle Warnungen zu erhalten. Wenn Sie eine IDE wie Eclipse verwenden, würde dies automatisch geschehen.

1416840cookie-checksegfault nur, wenn KEIN Debugger verwendet wird

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy