Exception beim Zugriff auf einen Null-Pointer abfangen.

Hallo,

ich habe irgendwo im Programm eine sehr schwer reproduzierbare
Exception - Zugriff auf einen NULL-Pointer.

Wollte die Exception so abfangen:

try{

//Hier passiert irgendwo der Zugriff auf den NULL-Pointer
}
catch( ... ){

// Hier könnte ich dann die Exception abfangen
}

Geht aber nicht.

Weiß jemand , wie ich die Exception abfangen kann ?

Viele Grüße,
Elke

THX 1138

Elke100 schrieb:

Geht aber nicht.

Was geht nicht?

mawis

Elke100 schrieb:

ich habe irgendwo im Programm eine sehr schwer reproduzierbare
Exception - Zugriff auf einen NULL-Pointer.

Wollte die Exception so abfangen:

Ich kenne deinen konkreten Fall nicht. Vielleicht hast du ja ein Stück Code, das auf NULL-Pointer überprüft und dann eine Exception wirft. Aber im Allgemeinen wirft ein Zugriff auf einen NULL-Pointer keine Exception, sondern führt direkt zum Programmabbruch durch das Betriebssystem.

Wo der Zugriff auf den NULL-Pointer erfolgt solltet du mit einem Debugger relativ einfach finden können. Dort im Code kannst du dann einfach sowas wie das folgende machen:

if (pointer_der_NULL_sein_koennte == NULL)
    throw std::string("Oops, da war der NULL-Pointer");

Diese Exception kannst du dann fangen.

LordJaxom

Du könntest das Programm aber auch in einem Debugger laufen lassen (alternativ Speicherabbild überprüfen), der sagt Dir i.A. wo das Programm durch einen Speicherfehler beendet wurde.

Das ist ein sehr komplexes Programm mit Zugriffen auf die DB , Mittelschicht usw. Und der Fehler ist nicht reproduzierbar.

Wenn ich den Fehler reproduzieren könnte, dann wäre es kein Problem , den Fehler mit dem Debuger zu finden.

Vile Grüße, Elke

Es soll natürlich heißen: Viele Grüße

Artchi

Kann es sein, das du vorher Java programmiert hast? Weil da kann man eine NullPointerException abfangen, aber es handelt sich dann um eine von der VM geworfene Exception. Soll heißen, eine Software-Exception. Wenn du aber bei C++ auf einen ungültigen Pointer zugreifst, ist es eine Hardware-Exception, weil das die CPU wirft. Deshalb hilft dir das catch(...) nicht viel.

Nein , habe ich nicht

Habe nur gedacht , dass ich den Fehler so abfangen kann.
Schade , dass es nicht geht

Danke !

LG, Elke

mawis

Elke100 schrieb:

Wenn ich den Fehler reproduzieren könnte, dann wäre es kein Problem , den Fehler mit dem Debuger zu finden.

Unter welchem OS läuft das Programm denn? Unter Windows sollte der Debugger bei einer Speicherzugriffsverletzung doch selbst aufgehen wenn du Visual Studio installiert hast.
Und unter UNIX kannst du dir vom OS ein core-File schreiben lassen, wenn der Zugriff auf den NULL-Pointer stattfindet und dieses core-File dann mit dem Debugger laden und dir anschauen wo der Fehler auftrat.

mawis

Elke100 schrieb:

Habe nur gedacht , dass ich den Fehler so abfangen kann.
Schade , dass es nicht geht

Naja einen Zugriff auf einen NULL-Pointer kannst du schon abfangen, allerdings nicht mit einer Exception. Unter einem POSIX-kompatiblen Betriebssystem kannst du dazu einen Signal-Handler für das Signal SIGSEGV registrieren (siehe man 2 signal und man 7 signal), der aufgerufen wird, wenn ein Zugriff auf eine ungültige Speicheradresse stattfindet (und ein Zugriff auf NULL ist ein solcher).

Allerdings musst du dich bei sowas eben ziemlich auf die Niederungen des Betriebssystems und C herunterlassen, so dass ein Debugger-Einsatz vermutlich einfacher ist (und ich diesen immernoch für möglich halte).

Knuddlbaer

Wenn das Ergebnis im Debugmodus nicht auffindbar ist, könnte auch irgendwo eine nicht initialisierte Variable für den Zugriff sorgen.

Welchen Compiler setzt Du ein ? Vllt. hilft es, wenn Du es als Release kompilierst aber Debuginformationen generieren lässt. Es wird ein try and error werden um den Fehler zu finden.

Vllt. hilft es, wenn Du es als Release kompilierst aber Debuginformationen >generieren lässt. Es wird ein try and error werden um den Fehler zu finden.

Wie meinst du das ? Wenn ich eine Release-Version erstelle , dann kann ich doch keine Debug-Informationen nutzen ?

Mfg, Elke

Unter Windows sollte der Debugger bei einer Speicherzugriffsverletzung doch <selbst aufgehen wenn du Visual Studio installiert hast.

Der Fehler tritt irgendwann auf, er ist eben nicht reproduzierbar. d.h. die Anwendung läuft ein-zwei Wochen und dann stürzt sie ab.

Mfg, Elke

Knuddlbaer

Doch geht schon, deswegen halt die Frage nach dem Compiler. Den VC8 kannst Du dennoch Debuginformationen erzeugen lassen. Der Debugger bleibt dann zumindest mal im Quellcode stehen und die Variablen werden nicht vorinitialisiert.

Sporadische Fehler zu finden ist sehr schwer. Du wirst Dir anhören müssen wann der Fehler auftritt und lange danach suchen dürfen. Erst recht wenn das "Problem" durch die Umgebung ausgelöst wird.

Häufig kommen die Probleme durch mangelnde Abfragen oder initialisierungen. Hier hilft nur viel geduld und raten weiter. Lass Dir die Fehler so gut wie Möglich beschreiben und versuche die Grenzen von mal zu mal einzuschränken.

Aber kommen wir mal mehr zu den Details:

welches OS, welcher Compiler welche Libs ? (Windows API, MFC, .Net oder was es unter Linux gibt (sry kenn ich mich nicht mit aus , nie mit GUI unter Linux entwickelt)).

Eventuell kann man anhand dessen Tips geben oder verschieben um spezielle Features nutzen zu können.

welches OS, welcher Compiler welche Libs ? (Windows API, MFC, .Net oder was >es unter Linux gibt

Windows, VC7.0 , .Net , Mfc

Danke !

Mfg , Elke

C++ Forumbot

Dieser Thread wurde von Moderator/in HumeSikkins aus dem Forum C++ in das Forum MFC (Visual C++) verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

Knuddlbaer

Wenn der Fehler auftritt, gibt es dann eine große Messagebox bzw. einen Hinweis auf nen Jit debugger oder sowas ?

Hast Du wirklich .Net mit MFC gemischt vorliegen ? (Mixed Code)

[edit]Na, das hätte eventuell auch in C++/CLI passen können[/edit]