Rückgabe Variant

Oh.

Wenn Du schon klar einen VT_BSTR zuweist, dann solltest Du auch VT_BSTR direkt setzen. Und höchstens vorher noch einen ASSERT Test machen.

Jetzt habe ich das erst verstanden! m_varianttype ist immer VT_BSTR.

Dachte du meinst ich soll keinen CString verwenden. Habe nicht genau gelesen sorry.

Nochmals kurz zu dem Rückgabewert VARIANT

Wenn nun der VARIANT nun ein Member meiner Klasse ist und ich gebe diesen als Kopie zurück muss ich dann VariantClear ausserhalb aufrufen und auch VariantClear im Destruktor meiner Klasse.

Wie verhält sich das ganze wenn ich eine konstante Referenz des VARIANTS zurückgebe?

Belli

Da VARIANT keinen eigenen Destruktor hat, musst Du jeden VARIANT genau einmal via VariantClear zerstören, damit seine Ressourcen freigegeben werden.
Immer vorausgesetzt, er belegt überhaupt welche, siehe vorherige Posts.
Wenn Du einen VARIANT durch einfache Zuweisung oder Rückgabe aus einer Funktion, wie der TE, erhalten hast, darfst Du den maximal einmal zerstören, weil keine tiefe Kopie erstellt worden ist.
Wenn Du einen mit VariantCopy kopiert hast, hast Du eine tiefe Kopie erstellt, und musst zu gegebener Zeit beide, Quelle und Ziel, zerstören.

Und bei Rückgabe als Referenz verhält es sich wie mit einer Kopie

Was muss ich machen dass VariantClear nicht zum Absturz meines Programmes führt.

Gibts da ne Überprüfung "Variant bereits gelöscht?", oder kann ich eine Exception abfangen?

Martin Richter

VariantCLear führt dann zum Absturz, wenn Du einen Speicher zum Beispiel zweimal freigibst.

VARIANT var1, var2;
var1.vt = VT_BSTR;
var1.bstrVal = anystr.AllocSysString();
var2 = var1;
VariantClear(&var1);
// Crash!
VariantClear(&var2);

Ist doch logisch.

Arbeite mit CComVariant und Du hast die Probleme nicht.

Und solche Exceptions kann man nicht abfangen und sie dann vor allem korrekt behandeln...

Selbst wenn andere ein VARIANT verwenden, so doch eher VARIANT*! Und hier ist die Behandlung transparent... und selbst wenn nicht. Kannst Du ja jederzeit aus einem CComVariant eine Kopie erzeugen.!

Ist doch logisch.

Ja in dem einfachen Beispiel schon.

Mein Programm besser gesagt meine DLL stürzt ab und zu ab. Ich kann aber nicht lokalisieren wo.

Selbst wenn andere ein VARIANT verwenden, so doch eher VARIANT*!

Was meinst du mit "so doch eher VARIANT*"

Martin Richter

Zeiger auf einen Variant.

Debugge doch. Wenn es crashed kannst Du doch die Codestelle ausmachen.

Zeiger auf einen Variant.

Das ist klar

Selbst wenn andere ein VARIANT verwenden, so doch eher VARIANT*!

Du meinst ich soll einen Zeiger auf Variant verwenden?

Debugge doch. Wenn es crashed kannst Du doch die Codestelle ausmachen.

Schön wärs. Ich kompiliere eine DLL diese stellt Exportfunktionen bereit die wiederum von WinCC (script.exe) verwendet werden.

Um nun mein Programm debuggen zu können muss ich mich an den Prozess anhängen.
Stürzt nun das Programmm ab bleibe ich sehr wohl mit dem Debugger hängen. Der besitzt aber einen Aufrufstack der nichts mit meiner DLL zu tun hat.

Da liegt jetzt die Annahme nahe dass es nichts mit meiner DLL zu tun hat. Verwende ich nun aber eine Vorgängerversion meiner DLL aus dem Repository führt es nicht zu einem Absturz.

Vergleiche ich nun die beiden Versionen im Repository sind hier nur Änderungen im Code mit dem Handling der VARIANTS zu verzeichnen.

Ich hatte an 4 Stellen VariantClear hinzugefügt weil wir über einen längeren Zeitraum einen Speicheranstieg zu verzeichnen hatten. Dieser ist nun nach dem einfügen von VariantClear weg.

Dafür stürzt das Programm ab. Leider aber nur sehr unregelmässig.

Debuggen bringt mich leider nicht weiter.

Swordfish

Dann wird VariantClear() wohl mehrmals für den selben VARIANT aufgerufen bzw. für mehrere, die die selben Ressourcen halten.

Martin Richter

Wenn der Heap zerstört wird, dann kann der Crash auftreten wann auch immer das eben entdeckt wird.
Und dennoch kann man das Debuggen.

Einfach nur VariantClear einstreuen ist nicht sonderlich intelligent.
Die Frage ist wem, der VARIANT gehört.

Wenn der Heap zerstört wird, dann kann der Crash auftreten wann auch immer das eben entdeckt wird.
Und dennoch kann man das Debuggen.

Ok und wie. Ich schalte alle Exceptions ein habe an allen VariantClear ein Breakpoint gesetzt. Lieder habe ich ein paar HundertInstanzen. Stichprobenmässig sind die VariantClear alle in Ordnung.

Einfach nur VariantClear einstreuen ist nicht sonderlich intelligent.

Wer sagt den das die irgendwo eingestreut wurden.

Ich habe mir schon was dabei gedacht. Bin nun auf Fehlersuche und habe mich nun nochmals versichert dass ich mit den Variants alles richtig verstanden habe. Oder halt doch noch nen bug drin habe.

Mag sein dass ich vieleicht einmal zu viel VariantClear aufgerufen habe. Aber das will ich ja nun finden.

Wie kann man den davon ausgehen, nur weil man auf der Suche nach einem Fehler ist das man das was man gemacht hat einfach nur willkürlich ist???

Martin Richter

Starte die Script.exe im Debugger. Dadurch wird der Debug-Heap aktiv. Das sollte direkt zu einem Stop führen wenn der Heap zerstört wird.

Man kann die Script.exe nicht im Debugger starten, mir ist zumindest nicht bekannt wie.

Ich weiß nicht ob du WinCC von Siemens kennst. Das ist eine Applikation für die Visualisierung im Bereich der Automatisierung.

In diesem WinCC lässt sich C programmieren. Um irgendwelche koplexeren Aufgaben zu erledigen schreiben wir eigene C++ Dll's deren Exportfunktionen sich wiederum in diesem sogenannten c-script aufrufen lassen.

Diese Script.exe wird von WinCC gestartet und fürt dann das ganze aus.

Der Editor ist ziemlich rudimentär. Er bietet auch keinen Debugger.

Wenn irgendeine DLL eine Exception wirft stürzt die script.exe ab und das wars dann.

Ich habe bisher nur die Möglichkleit gefunden, die debug Version meiner DLL abzulegen und mich mit Visual Studio an die Script.exe anzuhängen. Bisher habe ich so immer zuverlässig meine Fehler gefunden.

Nur in diesem Fall lande ich irgendwo im Nirvana.

siehe http://stackoverflow.com/questions/1010106/how-to-debug-heap-corruption-errors

insbesondere die 2te Antwort zum Thema PageHeap via gflags.exe

Hallo

Danke euch ihr habt mir schon ein ganzes Stück weitergeholfen.

Noch ne weitere Frage:

VARIANT var1;
var1.vt = VT_BSTR;
var1.bstrVal = anystr.AllocSysString();

reicht es hier VariantClear(&var1) aufzurufen.
oder muss ich auch noch SysFreeString(var1.bstrVal); aufrufen

Belli

Eines von beiden musst Du aufrufen. VariantClear ist normalerweise das Mittel der Wahl, weil Du dann nicht selbst nachhalten musst, was überhaupt in Deiner Variablen drin ist.
VariantClear kümmert sich dann auch um die Freigabe des bstrVal. Du kannst den natürlich auch selbst freigeben, und Dir dann VariantClear sparen ...

Ok. Dann ist VariantClear die richtige Wahl.

Meinen Absturz habe ich gefunden. VariantClear einmal zu viel aufgerufen. War aber so erst gar nicht ersichtlich.

Der Speicheranstieg scheint aber woanders herzukommen. Den einzigen Speicher den ich im Zusammenhang mit den Variants allokiere sind ein paar Strings. Die ich nun auch sauber wieder freigebe.

Alle anderen Variants die ich ständig anlege und lösche beinhalten nur einfache Datentypen, short, int, double usw. Gebe ich auch wieder frei mit VariantClear, sollte ich dies aber irgendwo vergessen haben sollte dies nicht der Grund für meinen Speicheranstieg sein.

Nun geht die Suche woanders weiter. Danke nochmals für eure Hilfe. Auch wenn es ein paar Startschwierigkeiten gab.