Access Violation in DLL

[donvido (Gast)]

Hallöchen,

Ich habe in dem Code an dem ich arbeite ein Problem dieser Art
https://blogs.msdn.microsoft.com/larryosterman/2004/04/22/when-global-destructors-bite/
entdeckt, dass sich bisher nicht bemerkbar gemacht hat.
Und zwar wird eine DLL erzeugt, die in unterschiedlichen Programmen 
eingebunden wird. Innerhalb der DLL wir ein XML mit Hilfe der ATL-Lib 
eingelesen. Jetzt ist erstmals dieses Problem aufgetreten, obwohl der 
Code so auch in den anderen Programmen verwendet wurde.

Meine Fragen:
1. Können Programme Access Violations unterdrücken, sodass kein Fehler 
produziert wird? Ich weiß dass das eine Programm in Delphi geschrieben 
ist (dort funktioniert es) und das andere scheint in Fortran geschrieben 
zu sein (hier lautet die Fehlerausgabe "forrtl: severe <157>: ...")

2. Ich habe in meinem Code das CoUninitialize(); auskommentiert und das 
Programm läuft durch. Muss ich schwerwiegende Probleme befürchten?
Ich habe von der ATL-Lib leider nicht viel Ahnung.

[Jim M. (turboj)]

donvido schrieb:
> 1. Können Programme Access Violations unterdrücken, sodass kein Fehler
> produziert wird?

Nein.

Man kann höchstens mit
try {} catch {}

arbeiten, aber bei Acces Violations gibt es gerne mal Folgefehler.

donvido schrieb:
> Muss ich schwerwiegende Probleme befürchten?

Woher zum Teufel sollen wir das wissen? Den Source Code haben wir nicht 
vorliegen.

[donvido (Gast)]

Jim M. schrieb:
> Woher zum Teufel sollen wir das wissen? Den Source Code haben wir nicht
> vorliegen.

Den Link hast du aber gecheckt oder?

[donvido (Gast)]

Wie meinst du das mit den Folgefehlern?

[Nop (Gast)]

donvido schrieb:
> Wie meinst du das mit den Folgefehlern?

Wenn ein Programm nicht das tun kann, was es soll, dann fehlen bestimmte 
Operationen. Sofern die wichtig waren, funktioniert das Programm danach 
nicht mehr wie beabsichtigt.

Wenn Du am Geldautomaten eine access violation bekommst und daher die 
Operation "Geld abheben" nicht sauber durchführen kannst, wird als 
Folgefehler davon Dein Einkauf spätestens an der Kasse auch scheitern.

[M.K. B. (mkbit)]

Du sagst der Fehler tritt auf, wenn du CoUninitialize() auskommentierst.

Ohne deinen Code zu kennen würde ich mal darauf tippen, dass du in der 
DLL Speicher allozierst und diese nach dem Unload der DLL noch 
verwendest, aber die DLL ihren Speicher schon freigegeben hat.
Es reicht auch, wenn du aus der DLL ein Objekt als Pointer bekommst und 
es nicht oder nicht vor dem Unload der DLL zurückgibst.

[donvido (Gast)]

M.K. B. schrieb:
> Du sagst der Fehler tritt auf, wenn du CoUninitialize()
> auskommentierst.

Dann tritt der Fehler nicht mehr auf.

Der  Code sieht ungefähr so aus

 void foo(char *inputFileName){

    CoInitialize(NULL);
    CComPtr<IXMLDOMDocument> iXMLDoc;
    iXMLDoc.CoCreateInstance(__uuidof(DOMDocument));
    iXMLDoc->load(CComVariant(inputFileName),&bSuccess);
    CComPtr<IXMLDOMElement> iRootElm;
    iXMLDoc->get_documentElement(&iRootElm);
    TElem eroot(iRootElm);
    
    do_something(); 

    CoUninitialize();
}

Ich habe wie gesagt von der ATL-Lib nich viel Ahnung.

[M.K. B. (mkbit)]

Entschuldige den Schreibfehler, aber der Fehler ist genau der, den ich 
vermutet habe.
Ich habe mal nicht relevante Teile im folgende Code weggelassen.

Erklärung des Problems:

 void foo(char *inputFileName){

    CoInitialize(NULL);
    CComPtr<IXMLDOMDocument> iXMLDoc;
    // Im Heap der DLL wird Speicher für ein DOMDocument reserviert
    // und die Lebenszeit vom CComPtr hier kontrolliert
    iXMLDoc.CoCreateInstance(__uuidof(DOMDocument));
    // Gleiches wie oben für RootElement.
    CComPtr<IXMLDOMElement> iRootElm;
    iXMLDoc->get_documentElement(&iRootElm);

    do_something(); 

    // DLL wird freigegeben und damit wird auch der Heap
    // der DLL freigegeben.
    CoUninitialize();

// Hier werden die CComPtr zerstört und wollen Objekte aus der DLL freigeben,
// aber der DLL Heap wurde ja schon freigegeben und gehört nicht
// mehr zum Prozessspeicher => Access Violation
}

Lösung 1:

 void foo(char *inputFileName){

    CoInitialize(NULL);
    CComPtr<IXMLDOMDocument> iXMLDoc;
    iXMLDoc.CoCreateInstance(__uuidof(DOMDocument));
    CComPtr<IXMLDOMElement> iRootElm;
    iXMLDoc->get_documentElement(&iRootElm);

    do_something(); 

    iRootElm.Reset();
    iXMLDoc.Reset();    

    CoUninitialize();
}

Lösung 2:

 void foo(char *inputFileName){

    CoInitialize(NULL);
    {
        CComPtr<IXMLDOMDocument> iXMLDoc;
        iXMLDoc.CoCreateInstance(__uuidof(DOMDocument));
        CComPtr<IXMLDOMElement> iRootElm;
        iXMLDoc->get_documentElement(&iRootElm);

        do_something(); 
    } // CComPtr werden hier zerstört

    CoUninitialize();
}

[donvido (Gast)]

Vielen Dank, das ist doch mal was.


Um nochmal auf meine 2. Frage zurückzukommen habe ich das ganze nochmal 
angepasst.

 void foo(char *inputFileName){

    CoInitialize(NULL);
    CComPtr<IXMLDOMDocument> iXMLDoc;
    // Im Heap der DLL wird Speicher für ein DOMDocument reserviert
    // und die Lebenszeit vom CComPtr hier kontrolliert
    iXMLDoc.CoCreateInstance(__uuidof(DOMDocument));
    // Gleiches wie oben für RootElement.
    CComPtr<IXMLDOMElement> iRootElm;
    iXMLDoc->get_documentElement(&iRootElm);

    do_something(); 

    // DLL wird nicht freigegeben und damit wird auch der Heap
    // der DLL nicht freigegeben.
    // CoUninitialize();

// Hier werden die CComPtr zerstört und wollen Objekte aus der DLL freigeben,
// der DLL Heap wurde noch nicht freigegeben und gehört noch
// zum Prozessspeicher => keine Access Violation
// Die DLL bleibt eingebunden bis zum Programmende
}

Die Funktion wird zur Programmlaufzeit nur ein einziges Mal aufgerufen. 
Die DLL würde also unnötigerweise eingebunden bleiben aber das sollte 
doch das einzige Problem sein oder? Damit bräuchte ich den Programmcode 
nämlich nur minimal anfassen.