FreeLibrary oder UnloadPackage in Finalization

[QuickAndDirty]

FreeLibrary wirft im Finalization Teil eine Exception.

Ich lade die DLLs und Packages dynamsch.
Passiert das entladen der DLLs automatisch vor dem Finalization Teil so das es ein Fehler ist das dort zu machen?

Gilt das selbe auch für den UnloadPackage Befehl?

[himitsu]

Hast du mal ein Beispiel?

Ich hatte jedenfalls noch keine Probleme eine DLL an dieser Stelle zu entladen.

[QuickAndDirty]

Das wäre der teil in dem es passiert.
hier werden im Finalization alle plug-ins augeladen

Delphi-Quellcode:

If Libs[index].TheLibKind  = lkBPL then
  UnloadPackage(Libs[index].TheLibHandle)
else if Libs[index].TheLibKind  = lkDLL Then
  FreeLibrary(Libs[index].TheLibHandle); //  <--- hier kommt die exception
Flist[index] := nil;
Flist.Delete(index);

Das ganze System oder auch nur die unit sind wohl zu groß um hier hochgeladen zu werden.
Vermutlich müsste ich ein test Programm schreiben....
...dumm nur das der Fehler in einem Testprogramm auftritt in dem ich etwas ganz anderes testen wollte.


Edit1: Das handle das freigegeben wird ist auch das selbe das erzeugt wurde. Und es wurde auch mit Loadlibary erzeugt.

[himitsu]

FreeLibrary erzeugt von sich aus aigentlich nur selten eine Exception.
Wird vielleicht innerhalb der DLL, beim Entladen, auf etwas anderes zugegriffen, welches zu diesem Zeitpunkt schon entfernt wurde?



Weiß ja nicht, was sonst noch für Code behandelt wird, aber wenn nur die Liste abgearbeitet und alles freigegeben werden soll:

Code:

[s]for index := Libs.Count - 1 downto 0 do
  case Libs[index].TheLibKind of
    lkBPL: UnloadPackage(Libs[index].TheLibHandle);
    lkDLL: FreeLibrary(Libs[index].TheLibHandle);
  end;
Libs.Free;[/s]

[edit] seh grad, daß da zwei Listen (Libs und FList) parallel verarbeitet werden

[QuickAndDirty]

Zitat:

Zitat von himitsu

FreeLibrary erzeugt von sich aus aigentlich nur selten eine Exception.
Wird vielleicht innerhalb der DLL, beim Entladen, auf etwas anderes zugegriffen, welches zu diesem Zeitpunkt schon entfernt wurde?

Das könnte sein, Freelibrary macht ein Detach Process ja?

Aber wie kommt dann die Zugriffsverletzung in hoch? Die kann doch eigentlich nicht von dem DLL in das Pragramm rüber, oder?

EDIT1: Nur ATTACH_PROCESS getriggert, also das kann es nicht sein.

[himitsu]

Laufen die Finalisierungen der DLL nicht im selben Thread ab, von wo aus auch FreeLibrary aufgerufen wurde?
Dann müßten die Exceptions in der DLL doch im selben Kontext ablaufen, also auch in der EXE zu spüren sein. :gruebel:

[QuickAndDirty]

Zitat:

Zitat von himitsu

Laufen die Finalisierungen der DLL nicht im selben Thread ab, von wo aus auch FreeLibrary aufgerufen wurde?
Dann müßten die Exceptions in der DLL doch im selben Kontext ablaDoch eigentlich isteufen, also auch in der EXE zu spüren sein. :gruebel:

+

Die Anwendung hat nur einen Thread. Ok.

Edit 1: Es ist aber kein Problem sowas in Finalization zu machen ja? ich darf den Fehler als woanders suchen?

Edit 2: Das ist auch in der IDE keine Problem?

[QuickAndDirty]

Ok Ich habe es....

....
Die DLL nutzt Sharemem....und im Testprojekt habe ich vergessen die sharemem Unit als erstes einzubinden...
...
die Stelle an der der Fehler passiert ist vermutlich eher Zufall gewesen....

man möge mich steinigen.

Auf die Uhr seh...wie teuer war der Fehler jetzt ? so ein scheiß