try catch und Release Version

simon.gysi

@Softwaremaker
Ich denke nicht, dass es etwas mit der Optimierung zu tun hat.

Ich denke es ist viel eher so, dass es eben "Zufall" ist, ob eine Access Violation stattfindet oder nicht, da test (im Release Mode) nicht initialisiert ist.

int *test;
*test = 13;

So würde auch im Release Mode eine Access Violation stattfinden.

int *test(0);
*test = 13;

Im Debug Mode initialisiert der Debugger test automatisch mit 0, desshalb "funktioniert" im Debug Mode auch das try/catch.

Dies nur zum Verständnis, ansonsten ist die Variante von Martin Richter vorzuziehen.

Grüsse Simon

BOA

Softwaremaker schrieb:

Das Problem, dass try-catch nicht im Release-Build funktioniert, liegt wahrscheinlich an der Optimierungseinstellung des Compilers (MS Visual C++).
Stelle mal im Projekt die C++ Compiler Optimierung auf Standard und nicht auf Geschwindigkeit/Größe optimieren (/O1 /O2).
Dann klappt try-catch auch im Release-Build.

siehe auch http://members.cox.net/doug_web/eh.htm

Der Compiler schmeisst bei Optimierung anscheined den try-catch-Mechanismus raus, weil kein throw() im try-block ist.

Update:
oder einfach vor und nach der Funktion die Optimierung aus-/einschalten:
#pragma optimize("", off)
void UnsichereFunktion()
{
 try{}
 catch(...){}
}
#pragma optimize("", on)

Nun klappt es auch im Release Modus...
Danke!!! Das hilft mir sehr....

@Martin
Auf die Gefahr hin, dass Du mich künftig meidest. Wie soll ich das Ding als Projekt öffnen ? Das ist ja eine dmp-Datei.
Ich würde gerne staunen...

Grüße und Danke

BOA

BOA

simon.gysi schrieb:

@Softwaremaker
Ich denke nicht, dass es etwas mit der Optimierung zu tun hat.

Ich denke es ist viel eher so, dass es eben "Zufall" ist, ob eine Access Violation stattfindet oder nicht, da test (im Release Mode) nicht initialisiert ist.
int *test;
*test = 13;
So würde auch im Release Mode eine Access Violation stattfinden.
int *test(0);
*test = 13;
Im Debug Mode initialisiert der Debugger test automatisch mit 0, desshalb "funktioniert" im Debug Mode auch das try/catch.

Dies nur zum Verständnis, ansonsten ist die Variante von Martin Richter vorzuziehen.

Grüsse Simon

Hi,

danke für die Ergänzung, allerdings kommt beim deinem Quälcode ne Fehlermeldung, sprich das Programm läuft gar nicht erst los...

Die Lösung von Softwaremaker ist schon genau, was ich gesucht habe, nun isses nicht mehr so optimiert, aber bis zur Fehlerfindeung kann ich in allen erdenkliche Variationen reagieren.

Danke und Grüße

BOA

simon.gysi

Quälcode

ui.. schon so gequält..

Nein, ernsthaft. Meinst Du ein Compiler Fehler?
Dann versuchts mit:

int *test = 0;
*test = 13;

Gruss Simon

Artchi

Ergänzung zum Dump (finde ich auch eine super Sache!): Auf welchem Warnlevel arbeitest du? Wenn du den Warnlevel höher setzt, hätte der Compiler dir bestimmt gesagt, das test nicht korrekt initialisert wurde. Das hindert dich zwar nicht das Ding trotzdem auszuführen, aber er hat dich schon beim Kompilieren auf eine potenzielle Gefahrenquelle hingewiesen. Damit kann man schon mal Ärger minimieren.

BOA

simon.gysi schrieb:

Quälcode

ui.. schon so gequält..

Nein, ernsthaft. Meinst Du ein Compiler Fehler?
Dann versuchts mit:
int *test = 0;
*test = 13;
Gruss Simon

Genau,

Compilerfehler, war schlecht ausgedrückt von mir...

Grüße

BOA

BOA

Artchi schrieb:

Ergänzung zum Dump (finde ich auch eine super Sache!): Auf welchem Warnlevel arbeitest du? Wenn du den Warnlevel höher setzt, hätte der Compiler dir bestimmt gesagt, das test nicht korrekt initialisert wurde. Das hindert dich zwar nicht das Ding trotzdem auszuführen, aber er hat dich schon beim Kompilieren auf eine potenzielle Gefahrenquelle hingewiesen. Damit kann man schon mal Ärger minimieren.

Hi,

ja das mit dem Dump würde ich auch gerne nutzen und verstehen. Da bin ich gerade dran, eventuell erbarmt sich Martin noc einmal, mir zu antworten...

Ja, klar, bei dem jetzigen Code warnt er natürlich. Ich wollte mit dem Beispielcode nur einen Abbruch erzwingen, um prinzipiell mein try catch Problem in Verbindung mit Release hier darzustellen...

Danke und Grüße

BOA

Softwaremaker

Also wenn ich bei eingeschalteter Optimierung /O2 folgendes ausführe:

try
{
   int *test=NULL;

   *test = 31;
}

catch(...)
{
   AfxMessageBox("try-catch ok");
}

Release: Windows-Fehlermeldung erscheint (catch wird nicht aufgerufen)
Debug: MsgBox "try-catch ok" (catch wird aufgerufen)
Im Debug ist Optimierung deaktiviert!

Release ohne Optimierung: MsgBox "try-catch ok" (catch wird aufgerufen)

-> Optimierung entfernt try-catch-Mechanismus

siehe auch: http://members.cox.net/doug_web/eh.htm
"...If you were to examine the assembly language emitted for this program, you would find the compiler has optimized all the exception handling machinery out of the function, because the optimizer can determine the tried code cannot throw a C++ exception."

(WinXP, VC++ 6.0)

Update:
aber wenn man nach
int *test=NULL;
ein "CString msg;" einfügt kommt catch auch bei Release mit Optimierung.
-> Sehr merkwürdiger Optimierer

simon.gysi

"...If you were to examine the assembly language emitted for this program, you would find the compiler has optimized all the exception handling machinery out of the function, because the optimizer can determine the tried code cannot throw a C++ exception."

Ja, aber die __try / __except (SEH) wird dann nicht weg optimiert.

catch(...) ist ein mix zwischen C++ Exception Handling und SEH.

Edit: Ist das Verhalten bei VS2005 / VS2008 dasselbe? VC++6.0 ist doch schon sehr in die jahre gekommen und nicht sehr ISO Compliant.

Martin Richter

Martin Richter schrieb:

Warum so kompliziert und DUMPCHK verwenden.

Nimm VS.
Öffne die DMP Datei als Projekt und sage einfach F5 (Start Debug) und staune...

Wie ich es gesagt habe.
Einfach auf Projekt Öffnen gehen. Dort alle Dateien (inkl. .dmp) anzeigen lassen. Die dmp Datei öffnen (ja das geht!), F5 drücken und jetzt Staunen...

hustbaer

OMFG.
Dashier ist schlimmer als wenn man dem Fleischer beim Wurst-Machen zusieht.
Ich werde nie wieder ein Programm anfassen welches ich nicht selbst geschrieben habe!

@BOA: Verwende doch bitte einfach _set_se_translator oder __try/__except.
z.B. so:

int poese()
{
	int volatile*p = 0;
	*p = 0;
	return 0;
}

int main()
{
	__try
	{
		return poese();
	}
	__except(EXCEPTION_EXECUTE_HANDLER)
	{
		printf("poese!!!\n");
		return 1;
	}
}

Und sag bitte nicht nochmal das funktioniere nicht. Das funktioniert! (Und _set_se_translator funktioniert auch)

BOA

hustbaer schrieb:

OMFG.
Dashier ist schlimmer als wenn man dem Fleischer beim Wurst-Machen zusieht.
Ich werde nie wieder ein Programm anfassen welches ich nicht selbst geschrieben habe!

@BOA: Verwende doch bitte einfach _set_se_translator oder __try/__except.
z.B. so:
int poese()
{
	int volatile*p = 0;
	*p = 0;
	return 0;
}

int main()
{
	__try
	{
		return poese();
	}
	__except(EXCEPTION_EXECUTE_HANDLER)
	{
		printf("poese!!!\n");
		return 1;
	}
}
Und sag bitte nicht nochmal das funktioniere nicht. Das funktioniert! (Und _set_se_translator funktioniert auch)

Hehe,

dann wirst Du viele gute und hilfreiche Programme nicht kennen lernen...
Vor allen Dingen so ohne Betriebssystem auf Deinem Rechner, viel Spass beim entwickeln...

Danke für Deinen Code, teste ich mal und berichte...

@Martin Richter
Ich glaube wir arbeiten mit verschiedenen Versionen, Martin.

Ich habe das VS 6, da kann ich nen Arbeitsbereich öffnen, aber kein Projekt, oder, ja schlagt mich, ich weiß net wo...

Ich weiß, ist ne schwere Geburt, aber das Kind scheint gesund, bitte hilf ihm...

Grüße und Danke

BOA

sri

Mit VS6 geht das noch nicht.

BOA

sri schrieb:

Mit VS6 geht das noch nicht.

Ahhhh....

Danke, ich war der Verzweiflung nahe...

Grüße

BOA

Martin Richter

Wer arbeitet auch noch mit VC6... <duck&wech>

BOA

hustbaer schrieb:

OMFG.
Dashier ist schlimmer als wenn man dem Fleischer beim Wurst-Machen zusieht.
Ich werde nie wieder ein Programm anfassen welches ich nicht selbst geschrieben habe!

@BOA: Verwende doch bitte einfach _set_se_translator oder __try/__except.
z.B. so:
int poese()
{
	int volatile*p = 0;
	*p = 0;
	return 0;
}

int main()
{
	__try
	{
		return poese();
	}
	__except(EXCEPTION_EXECUTE_HANDLER)
	{
		printf("poese!!!\n");
		return 1;
	}
}
Und sag bitte nicht nochmal das funktioniere nicht. Das funktioniert! (Und _set_se_translator funktioniert auch)

Hey,

funktioniert immer noch nicht...
Nur Spasss...
Jetzt funktioniert es, dank der Konstanten innerhalb der __except(). Muß einem doch gesagt werden...

Wobei ich dazu erwähnen muss, dass die andere Variante auch funktioniert, sprich viele Wege führen nach Rom.
So haben wir wenigstens alle mal durch...

Danke für die Hilfe.

Grüße

BOA

BOA

hustbaer schrieb:

OMFG.
Dashier ist schlimmer als wenn man dem Fleischer beim Wurst-Machen zusieht.
Ich werde nie wieder ein Programm anfassen welches ich nicht selbst geschrieben habe!

@BOA: Verwende doch bitte einfach _set_se_translator oder __try/__except.
z.B. so:
int poese()
{
	int volatile*p = 0;
	*p = 0;
	return 0;
}

int main()
{
	__try
	{
		return poese();
	}
	__except(EXCEPTION_EXECUTE_HANDLER)
	{
		printf("poese!!!\n");
		return 1;
	}
}
Und sag bitte nicht nochmal das funktioniere nicht. Das funktioniert! (Und _set_se_translator funktioniert auch)

Jetzt ist mir doch noch etwas aufgefallen. Ich bekomme folgende Warning beim Einsatz Deiner Variante :

D:\Microsoft Visual Studio\MyProjects\VTSM_Server\VTSM_ServerDlg.cpp(570) : warning C4509: Nicht dem Standard entsprechende Erweiterung : 'MessageReceive' verwendet SEH, und 'tUser' besitzt einen Destruktor

es wird innerhalb der "__try" tatsächlich ein Destruktor verwendet. Sowas macht mich schon wieder skeptisch und schärft die Überlegung doch nicht diese Variante zu nutzen, denn was will der Compiler mir sagen ?
Klar benutze ich nen Destruktor, warum schafft das ein Problem mit SEH ?

Nerv...

*Ergänzung*
Vor lauter warnings habe ich auch folgende Error Meldung bekommen :

D:\Microsoft Visual Studio\MyProjects\VTSM_Server\VTSM_ServerDlg.cpp(868) : error C2712: __try kann nicht in Funktionen verwendet werden, die eine Objektentladung benoetigen

Also, doch wieder zurück zur anderen Variante... Das nervt hier doch ungemein...

Grüße

BOA

simon.gysi

Weil beim SEH kein Stack Unwinding durchgeführt wird.
Der vorhandene Destruktor deutet jedoch darauf hin, es es nötig sein würde.

Desshalb meldet der Compiler dir die Inkompatiblität.

simon.gysi

Im MSDN nachlesen würde helfen.

BOA

simon.gysi schrieb:

Im MSDN nachlesen würde helfen.

Danke für den hinweis!

Oder aber Simon.gysi fragen...
Soziale Kontakte sind gerade für Softwareentwickler wichtig!

Grüße und Danke

BOA