Hello Michael,
Am 27.03.20 um 15:46 schrieb Michael Wojcik:
As a workaround, what about first making a JNI call to a trivial shared
object that does an explicit dlopen of the OpenSSL shared object? The
JVM wouldn't know about that load, and its subsequent unload of the
shared object wouldn't remove it from the process address space, because
there would still be a reference to it.
thanks for the suggestion. This sounds similar to the trick that is
already built into OpenSSL.
Through other channels I found now two other possible solutions for the
problem:
1) Use JNI_OnUnload() to call OPENSSL_cleanup()
JNI_OnUnload() is called when the JVM unloads the JNI library.
OPENSSL_cleanup() cleans up everything and no further per-thread cleanup
happens after unloading the JNI shared library.
2) Use a C++ static object in the JNI library where the destructor calls
OPENSSL_cleanup()
When debugging the problem I came across this neat trick on stackoverflow:
https://stackoverflow.com/a/11394263
class ResourceHolder {
public:
ResourceHolder() {
// at start
}
~ResourceHolder() {
// at exit
}
};
ResourceHolder theHolder;
I think that putting a call to OPENSSL_cleanup() into the destructor of
the ResourceHolder class would also fix the problem, and it would be
Java-agnostic.
Approach 1) does fix the crash for me. If approach 2) works as well, I
will use that one.
--
Stephan
