Seltsamer Absturz am Ende eines try{}, nichts ge-catch{}t



  • Hallo, ich hab ein seltsames Problem mit try/catch:
    Es gibt unregelmäßig Abstürze, die ich auf einen try/catch-block in einer Funktion, wie den unteren zurück führen konnte.

    {
       //...
    
       try{
          // ...
          printf("T ");
       }catch(...){
          printf("ARGH ");
       }
       printf("F ");
    }
    

    Also mal geschaut wie weit man kommt: Meistens läuft die Funktion einfach durch bis "F". Wenn sie abstürzt, kommt sie bis "T", ein "ARGH" gibts nicht.
    Kann mir jemand sagen, was da los ist? Compiler ist MinGW 4.7.1 meine ich..
    Und gibts noch andere Methoden, außer "printf()" dem Problem auf die Schliche zu kommen?

    MfG
    Kleee


  • Mod

    Präzisiere "Absturz"



  • Debugger sind eine gebräuchliche Methode.



  • Das Buffering kann dir bei solchen Diagnosen einen Strich durch die Rechnung machen.



  • Hallo,
    also Absturz:
    - mal garnicht
    - mal direkt zu Beginn ( 0xc0000005 )
    - mal mittendrin ( 0xc0000005 )
    - mal mit mal ohne windows-problemmeldung

    Beim debug-build muss man doch nur debug-symbols setzen, oder?! Was genau kann ich dann vom Debugger erwarten, wenns crasht?

    Mit Buffering meinst du das von der Konsole? Daran dachte ich auch schon. Aber wnn, dann gehts immer nur bis "T".



  • Kleee schrieb:

    Beim debug-build muss man doch nur debug-symbols setzen, oder?!

    Da du wohl Visual Studio benutzt: man wählt Debug aus der Klappliste.

    Kleee schrieb:

    Was genau kann ich dann vom Debugger erwarten, wenns crasht?

    Du willst wohl keine Hilfe ...



  • Da du wohl Visual Studio benutzt: man wählt Debug aus der Klappliste.

    CodeBlocks. ..MinGW wie gesagt..

    Du willst wohl keine Hilfe ...

    Ähm.. Alles klar?
    Also wenn der Debugger mir sagen sollte, durch welche Zeile der Fehler verursacht wird, dann tut er es jedenfalls nicht, trotz Symbolen..
    Oder wie geht man jetzt vor?!

    Jedenfalls, liegts nicht am try{}, crasht auch ohne. Was genau soll mir 0xc0000005 eigentlich sagen?



  • Kleee schrieb:

    Hallo,
    also Absturz:
    - mal garnicht
    - mal direkt zu Beginn ( 0xc0000005 )
    - mal mittendrin ( 0xc0000005 )
    - mal mit mal ohne windows-problemmeldung

    Dann wirst du wohl irgendwo auf Speicher zugreifen wo keiner ist. Wenns manchmal geht könnte es einfach ein ungültiger Array Index sein (negativ oder zu gross).

    Kleee schrieb:

    Beim debug-build muss man doch nur debug-symbols setzen, oder?!

    Äh. Nein?
    Hast du keine IDE? Hat dir deine IDE keine "Debug" Konfiguration angelegt?

    Kleee schrieb:

    Was genau kann ich dann vom Debugger erwarten, wenns crasht?

    Statt direkt wegzucrashen sagt dir dein Debugger dann dass da was passiert ist, und friert das Programm ein. Dann kannst du genau sehen wo es geknallt hat. Kannst du Variablen-Inhalte angucken, gucken von wo aus die crashende Funktion aufgerufen worden ist ("Callstack") usw. Sehr hilfreich.

    Kleee schrieb:

    Was genau soll mir 0xc0000005 eigentlich sagen?

    Das ist ein Exception Code.
    https://msdn.microsoft.com/en-us/library/cc704588(d=lightweight,l=en-us,v=PROT.10).aspx
    0xc0000005 heisst "access violation"



  • Gibt es bei Windows einen Handler für Stack-Overflow?

    Kleee schrieb:

    Was genau soll mir 0xc0000005 eigentlich sagen?

    Bei der Meldung werden noch ein paar mehr Zahlen/Adressen genannt.



  • Ganz abgesehen davon ist das keine C++ Exception, sondern eine Structured Exception vom Betriebssystem. Die kannst du nicht wie eine normale Exception fangen, sondern musst einen Structured Exception Handler (SEH) registrieren. Aber das ist wieder ein Thema für sich.



  • DocShoe schrieb:

    Die kannst du nicht wie eine normale Exception fangen, sondern musst einen Structured Exception Handler (SEH) registrieren.

    Müsste er. Ist aber nicht das richtige Mittel für das Problem das er hat. Access Violations kann man kaum sinnvoll behandeln. Der Fix ist den Bug im Code zu beheben - dann gibt es auch keinen Grund mehr eine SEH Exception behandeln zu wollen, weil keine SEH Exception mehr auftritt. Und falls doch irgendwann wieder eine auftritt will man normalerweise auch dass es crasht.



  • Ja, ich weiß. Ich wollte TE nur erklären, dass ein catch( ... ) nur C++ Laufzeitexceptions fängt. Eine Windows SE ist keine C++ Laufzeitexception und kann daher mit Standard C++ Mitteln nicht gefangen werden. Der Code 0xC0000005 steht für einen ungültigen Speicherzugriff, vermutlich schreibt er irgendwo in den Speicher oder versucht einen Nullpointer zu dereferenzieren.



  • Ich wollte nur nochmal konkret darauf hinweisen dass man das kann, aber meistens nicht sollte. Misverständnisse vermeiden. Dass du es nicht so gemeint hast hab ich mir fast gedacht, aber Anfänger können da schnell mal das falsche rauslesen/reininterpretieren.



  • @Kleee

    Poste doch mal den ganzen Code - wenn nicht zu gross



  • Hallo,
    Danke schon mal an alle.
    ..Also beim debuggen sollte man in der IDE auch den Debugger starten und nicht das Programm normal. Dann sieht man auch was.
    Allerdings schickt er mich dann quer durch die gcc-libs. Scheint (mal) was mit nem *NULL zu sein.. Ich benutze externe Libs, hoffentlich ist der Fehler nicht dort zu finden. Bei mir finde ich ihn allerdings nicht.
    Außerdem fängt er wohl weitere (structured) exceptions, die sonst garnicht aufgefallen sind, wenn ich das richtig verstehe.

    Wann werden diese structured exceptions denn raus gehauen??

    Der Code ist etwas zu lang, wenn man nicht weiß, welche Stelle genau in Frage kommt. Sowas wie "vec.push_back(std::vector<T>())", ist doch ok?!



  • Der Code ist etwas zu lang, wenn man nicht weiß, welche Stelle genau in Frage >kommt. Sowas wie "vec.push_back(std::vector<T>())", ist doch ok?!

    ja

    wenn du unter Linux(gcc) kompilieren kannst könntest du den AddressSanitizer verwenden - der zeigt dir schnell wo das Problem ist, oder auch z.B. valgrind

    https://stackoverflow.com/questions/37970758/how-to-use-addresssanitizer-in-gcc

    ansonsten kann du deinen Code auch auf pastebin.com posten und hier den Link einstellen



  • Kleee schrieb:

    Hallo,
    Danke schon mal an alle.
    ..Also beim debuggen sollte man in der IDE auch den Debugger starten und nicht das Programm normal. Dann sieht man auch was.
    Allerdings schickt er mich dann quer durch die gcc-libs. Scheint (mal) was mit nem *NULL zu sein..

    Hast du gefunden wie du dir den Callstack anschauen kannst? Da würdest du sehen von wo aus die gcc-lib Funktionen aufgerufen werden. Das reicht meistens schon um den Fehler zu finden.



  • Okay,
    hab den Fehler gefunden! Hatte natürlich was mit dem std::vector< std::vector<T> > zutun...
    Das mit dem Callstack muss ich mir nochmal ansehen. Richtig schlau bin ich nicht daraus geworden.
    Danke nochmal!



  • Kleee schrieb:

    Okay,
    hab den Fehler gefunden! Hatte natürlich was mit dem std::vector< std::vector<T> > zutun...
    Das mit dem Callstack muss ich mir nochmal ansehen. Richtig schlau bin ich nicht daraus geworden.
    Danke nochmal!

    Was genau hatte es denn mit dem Vector zu tun? Sowas ist immer interessant, vor allem falls mal jemand ein ähnliches Problem hat. Bisher wissen wir nur, dass du so eine Konstruktion hast du was drauf gepusht hast.



  • Ja, würde mich auch interessieren was das mit dem std::vector< std::vector<T> > zu tun hatte. Ist ja nicht grundsätzlich so dass so ein Konstrukt ein Problem darstellen würde.


Log in to reply