Hallo #,
besser kann ich es nicht erklären

Ich rufe in Programmteil A und B jeweils LoadLibrary auf,
mache in Programmteil B FreeLibrary und auch Programmteil A kann nicht mehr mit der Dll arbeiten:

Fehlermeldung: error creating SSL context

Das LoadLibrary/FreeLibrary mache übrigens nicht ich, sondern Indy mit den SSL-Dlls.

Beschrieben ist das u.a. hier:
https://forums.embarcadero.com/threa...62667&tstart=0
http://stackoverflow.com/questions/1...ndy-ssl-idhttp
http://atozedsoftware.newsgroups.arc...501123130.html

Im Moment behelfe ich mich mit einem Reload der Dlls,
nachdem der betreffende Code von Programmteil B gelaufen ist:

UnLoadOpenSSLLibrary;
LoadOpenSSLLibrary;

Schön ist das nicht, aber immerhin funktioniert es.

LoadLibrary und FreeLibrary besitzen eine Referenzzählung, also das ist schonmal nicht Schuld.

Allerdings hast du Pech, da LoadOpenSSLLibrary und UnLoadOpenSSLLibrary mit einem Singleton arbeiten und genau das machen, wonach sie klingen, egal wie oft man die aufruft.



Du könntest die Indy/Delphi-Sourcen ändern und eine Referenzzählung integrieren.

Du könntest UnLoadOpenSSLLibrary hooken und die Freigabe im Betrieb überspringen.

Oder du lebst mit deinem "Hack".
Kannst maximal noch ein LoadLibrary auf die DLL machen, damit zumindestens Diese nicht ständig neu geladen werden muß, falls es damit keine Probleme gibt.

Hallo zusammen,

ich bin aktuell auf ein sehr ähnliches Problem gestoßen und wollte fragen ob es hierfür eventuell eine Lösung oder einen Workaround gibt.

In meiner Anwendung lade ich dynamisch Dll's und gebe diese zur Laufzeit auch wieder frei.
Sowohl die Host-Anwendung als auch die Dll's nutzen die SSL Libs zur HTTP Kommunikation.
Sobald eine der dynamisch geladenen Dll's freigegeben wurde, funktioniert nun die SSL Geschichte nicht mehr in der Host-Anwendung: "error creating SSL context"

Im Prinzip dürfte das wohl hiervon kommen (IdSSLOpenSSL.pas):

markieren

Code:

finalization
  UnLoadOpenSSLLibrary;
  ...
end.

Leider gelingt es mir nicht das vernünftig abzustellen bzw. wenn es sein muss die SSL Bibliotheken neu zu laden.
Die Host-Anwendung scheint zu denken, dass die SSL Libs weiterhin geladen sind...

Ich setze XE5 ein.

Vielen Dank und viele Grüße!

Erstmal kannst du nur das machen, was der TE auch schon macht,

also nach dem Entladen deiner DLL auch in der EXE und den anderen DLLs die SSLLib neu laden.
Erst entladen und dann wieder laden, da LoadOpenSSLLibrary in einem Boolean speichert, ob es geladen wurde und dann nichts macht, wenn der noch True ist.

markieren

Delphi-Quellcode:

UnLoadOpenSSLLibrary;
LoadOpenSSLLibrary;

Natürlich überall zuerst Unload und danach Load, da die Unload ja ebenfalls alle Load wieder plätten, wenn die Reihenfolge nicht stimmt.

Und dann einen QC bei Embarcadero, bzw. eher eine Bug-Meldung an INDY.
http://www.indyproject.org/Support.DE.aspx
https://quality.embarcadero.com (alt: http://qc.embarcadero.com)

Hallo,

Zitat:

In meiner Anwendung lade ich dynamisch Dll's und gebe diese zur Laufzeit auch wieder frei.
Sowohl die Host-Anwendung als auch die Dll's nutzen die SSL Libs zur HTTP Kommunikation.
Sobald eine der dynamisch geladenen Dll's freigegeben wurde, funktioniert nun die SSL Geschichte nicht mehr in der Host-Anwendung: "error creating SSL context"

Das hatte mich zur fast Verzweiflung gebracht, bis ich die Ursache herausgefunden habe.
Mit meinem "Hack" klappt das aber jetzt.
Bei dir nicht?

Vielen Dank, dann werd ich das erstmal so als Workaround einbinden.
Die Issues mach ich am besten auch gleich auf.

Nochmal Danke und Grüße!

Zitat:

Mit meinem "Hack" klappt das aber jetzt.
Bei dir nicht?

Ich denke schon - nur ideal ist das nicht, da die SSL Libs recht lange (4s) zum laden und initialisieren benötigen...