Stapelüberlauf in nicht verwaltetem Zustand: IP: 0x26eb76, Fehleraddr: 0xbf808ffc

8

Meine Mono-Anwendung stürzt auf Mac mit dieser Nachricht ab ( Vollständiges Protokoll ):

%Vor%

"in unmanaged" bedeutet, dass der Stapelüberlauf nicht in meinem Code enthalten ist (ich habe nur Code verwaltet), sondern in einer Bibliothek, die ich eingebettet habe ( SQLite, DotCmis, NewtonSoft.Json ) oder in Mono-Code.

Obwohl ich kompiliere und im Debug-Modus laufe, bekomme ich nur diese zwei Hexadezimalzahlen.

FRAGE: Wie kann ich diesen Stack-Überlauf untersuchen? Irgendein Trick?

Hinweis: Die gleichen Bibliotheken (mit fast demselben Code) laufen unter Linux und Windows einwandfrei.

    
Nicolas Raoul 03.12.2012, 11:29
quelle

1 Antwort

4

Der Handling-Stack-Overflow ist ziemlich kompliziert (für Mono), so dass es sehr wahrscheinlich sein kann, dass der Stack-Überlauf tatsächlich Ihnen gehört. Das Problem liegt darin, die Stapelverfolgung herauszufinden.

Ich laufe normalerweise mit gdb:

%Vor%

Und dann versuchen Sie, Strg + C zu drücken, nachdem der Stack angefangen hat zu wachsen, aber bevor er tatsächlich überflogen ist (gdb wird ernsthaft mit Stack-Überläufen verwechselt, und Sie müssen gdb normalerweise beenden, wenn das passiert, weshalb Sie müssen den Überlauf in Aktion fangen).

Nachdem Sie Strg + C gedrückt haben, machen Sie thread apply all backtrace , und Sie werden wissen, ob ein Stack-Überlauf bevorsteht (ein Thread wird Tausende von Frames haben).

Sobald Sie eine riesige Stack-Trace in gdb haben, müssen Sie den Zyklus identifizieren. Dies ist normalerweise ziemlich einfach, wenn man nur die Adressen der Stapelverfolgung betrachtet. Sobald Sie diese Daten haben, können Sie den verwalteten Rahmen wie folgt erhalten:

%Vor%

Dann machen Sie das gleiche für alle Frames in dem gefundenen Zyklus.

Es gibt weitere Tipps zum Debuggen von Mono mit gdb hier .

    
Rolf Bjarne Kvinge 03.12.2012, 13:09
quelle