Wie Exceptions aktivieren?

[Hajoe]

Hallo,
der g++ Compiler weigert sich hartnäckig die Exception - Verarbeitung zu aktivieren. D.h die Exceptions werden von meinen Exception - Handlern nicht abgefangen. Ich hab's schon mit der Option -fexceptions probiert und in die configure.in habe ich unter CXXFLAGS auch schon $USE_EXCEPTIONS eingetragen,. woran kann's noch liegen?

[Savar]

was heißt "nicht abgefangen"? Fallen sie trotzdem bis nach oben durch? Wie sieht denn der catch Befehl aus?

[daedalus]

Ich würde den Fehler eher im Quellcode als bei den Compiler-Parametern suchen.

[Joghurt]

Dieses Programm

Code: Alles auswählen

#include <iostream>
using namespace std;

class MyException {};

int main()
{
   try {
      throw MyException();
      cout << "Hier stimmt was nicht..." << endl;
   }
   catch (MyException) {
      cout << "gefangen!" << endl;
   }
}

sollte "gefangen!" ausgeben. Wenn es das tut, ist der Fehler in deinem Code. Und da können wir dir nicht helfen, solange du ihn nicht postest (oder paste "nopaste"st)

[Hajoe]

Der Code sieht im wesentlichen so aus:

try
{
// hier passiert irgendein Mist
}
catch (std::bad_alloc &e)
{
printf ("Exception bad_alloc %s, line %d File: %s\n",e.what (),__LINE,__FILE__);
}
catch.. // hier kommen die anderen Standard - Handler
... // usw.
catch (...) // Zum Schluß alles abfangen
{
printf ("Unknown exception line %d File: %s\n",__LINE,__FILE__);
}

Im Fehlerfall bringt er nicht nicht das was die printf - Befehle ausgeben, sondern beispielsweise nur "Speicherzugriff" oder sowas ähnliches und das Programm beendet sich dann.

[Joghurt]

Ein Speicherzugriffsfehler kann nicht durch eine exception abgefangen werden! Wenn du eine Exception nicht abfängst, wird das Programm mit abort() beendet.

bad_alloc wird, IIRC, von malloc erzeugt, wenn es nicht genug Speicher hat.
Was bei dir passiert ist, dass du irgendwie über Speichergrenzen hinwegschreibst. Sowas kannst du nicht abfangen.

[Hajoe]

Das wäre aber schwach, unter Windows wird eine AccessViolation - Exception ausgelöst, die ich wunderbar abfangen kann.

[armin]

Dein Programm hat in diesem Fall nicht weiter zu laufen - du bist nämlich potentiell in einem Inkonsistenten Zustand.
Code fixen ist da die bessere Lösung...

[daedalus]

Windows ist dafür auch kein Betriebssystem (enthält keinen Compiler->es lassen sich mit Windows im Ursprungszustand keine Programme dafür erstellen->Kein OS per Definition). Wenn Du also vergleichen willst, dann bitte nur, was auch vergleichbar ist.

Bei Dir wird (vermutlich) auf einen ungültigen Speicherbereich zugegriffen. Warum es sinnvoll ist, bei diesem Versuch des Programm zu beenden, darfst Du Dir selbst überlegen. Die Exception wird (falls Du keinen großen, großen Bug im Programm hast) nicht von malloc() ausgelöst, wiel der Speicher ausgegangen ist. Poste doch mal den konkret den Fehler verursachenden Code, dann können wir Dir vielleicht weiterhelfen.

[Joghurt]

Das wäre aber schwach, unter Windows wird eine AccessViolation - Exception ausgelöst, die ich wunderbar abfangen kann.

Unter Linux kannst du auch mit signal SIGSEGV abfangen.

Bringt dir aber wie gesagt nicht viel. Wenn so ein Fehler auftritt, ist einiges im Argen und es ist in der Regel besser, das Programm zu beenden anstatt zu versuchen, weiterzumachen.

[peschmae]

Hab gerade etwas rumgelesen. Sonst hab ich keine Ahnung von so Zeugs - meine Programme die ich schreibe sind alle ganz brav und brauchen nie allen Speicher.

Ich denke der Punkt ist dass der Linux-Kernel das etwas anders handhabt. Sobald er keinen Speicher mehr zur Verfügung hat, aber neuen Speicher braucht, killt er den Prozess der (nach einem mysteriösen Algorithmus ausgesucht) zuviel Speicher verbraucht.
D.h. es kann durchaus auch sein dass dein Prozess gekillt wird weil er gerade der fetteste ist und laut dem Algo amok läuft auch wenn es im aktuellen Moment gerade ein anderer ist der eigentlich etwas Speicher braucht.

Das ganze hat soweit ich das sehe per se nichts mit einem Speicherzugriffsfehler im traditionellen Sinne zu tun(*) - auch wenn ein solcher ausgelöst wird. (Vielleicht auch doch - möglich dass er dem Prozess einfach den Speicher entzieht...)

Interessant dürfte für dich auch der Thread hier sein: http://lists.trolltech.com/qt-interest/ ... 177-0.html - dort schreibt einer: "My experience is that Linux gets exceedingly nasty when it runs out of memory...."

MfG Peschmä

(*) traditioneller Sinn: damit meine ich du schreibst in nur-lesbare Bereiche deines Adressraums

[Hajoe]

Mir geht's nicht darum in diesen Glaubenskrieg zwischen den dummen Gates - Anhängern und den supergeilen Pinguin - Jüngern einzusteigen. Der Vorteil wenn das ginge ist der, dass ich mir den Dateinamen und die Funktion (via __LINE__) in der das Malheur passiert ist ausgeben lassen kann. Unter Windows kann ich sogar mit __ThrowLineNumber die genaue Zeile ermitteln, hat aber irgendwie nie funktioniert ;-(
Signale abfangen bringt mir daher nix, ich will die Info wo was passiert ist.

[Hajoe]

PS.:
Es geht mir nicht um den einen konkreten Bug, das war ein ganz "normaler" Codierungsfehler wie er eben ab und zu vorkommt, sondern mir geht's ums Prinzip: Was für Diagnosemöglichkeiten habe ich unter Linux im Falle fehhlerhafter Codierung (was ja leider immer wieder vorkommt).

[peschmae]

PS.:
Es geht mir nicht um den einen konkreten Bug, das war ein ganz "normaler" Codierungsfehler wie er eben ab und zu vorkommt, sondern mir geht's ums Prinzip: Was für Diagnosemöglichkeiten habe ich unter Linux im Falle fehhlerhafter Codierung (was ja leider immer wieder vorkommt).

Meinst du jetzt damit dass das Problem bei dir nicht nur bei fehlendem Speicher auftritt? bzw. dass Joghurts Programm bei dir nie beim Catch vorbeikommt?
Dann wäre das allerdings ein Bug entweder bei dir im Gcc oder in der Standardbibliothek oder so.

MfG Peschmä

[GoKi]

Coredump erstellen lassen und dann mal mit ddd bzw gdb nachschauen hast Du schon porbiert?

Coredumps aktivieren

Code: Alles auswählen

ulimit -c unlimited

Nach dem Fehler sollte dann eine Datei namens core im aktuellen Verzeichnis liegen.

Dann z.B. ddd verwenden:

Code: Alles auswählen

ddd deinBinary core

Nun im Menü auf status - Backtrace klicken.

PS: Binary sollte natürlich mit der debug-Option kompiliert sein (-g)

[Hajoe]

Na, ich denke ich muss mich konkreter ausdrücken:
Das mit dem Speicherfehler war nur beispielhaft. Ich habe diesen Fehler nach einigem Suchen (ich wusste zuerst nicht wo es passiert) bereinigt. Daneben hatte ich auch noch eine Exception ausgelöst von der glibc (ungültiger Pointer oder so was, inzwischen bereinigt). Wenn man von vornerein wüsste wo ein Fehler auftritt kann man ihn schneller bereinigen, außerdem sind die unangenehmsten Fehler die, die beim Anwender auftreten. Mit meiner "Windows" - Methode bekommt der Anwender im Falle einer Exception dann meistens den Quelldateinamen und eine Zeilennummer die den ungefähren Ort angibt. Diese Information ist dann für mich sehr hilfreich in der Diagnose.
Ich verwende als IDE "Anjuta" (Version 2.02), leider funktioniert der Debugger unter dieser IDE (ich nehme mal an dass es an der IDE liegt) nicht richtig. Die Breakpoints setzt er nur, wenn er gut drauf ist und bei "Ausführen bis zum Cursor" hat er eine sehr eigene Meinung wo denn der Cursor gerade ist. Vielleicht sollte ich den Debugger mal außerhalb der IDE testen oder mal KDevelop testen (blöd nur, dass man dafür KDE braucht)

[armin]

Mit Eclipse lässt sichmitlerweile auch reht schön C/C++ coden und der Debugger funktioniert IMO auch ganz nett. Inclusive Backtraces

[Hajoe]

Ich dachte immer das ist ne Java - Entwicklungsumgebung? Ich werd das Teil mal inspizieren.

[armin]

Jo, du musst dran denke, dass CDT Plugin zu installieren.
Wenn du Eclipse 3.1 aus Debian nimmst kannst du es per apt installieren, willst du das neue 3.2 kannst du es per Updte-Manager einspielen.

[nepos]

Eclipse is ne IDE, primaer fuer Java, hat aber mittels Pluginsystem alles moegliche mitterweile mit drin.