Sean Soria added the comment:
You are correct, dlclose is called on libpythonXY.so and all .so modules loaded
by it.
--
___
Python tracker
<http://bugs.python.org/issue7
Sean Soria added the comment:
Simply unloading the callbacks wouldn't be wise. Callbacks are necessary for
proper thread safety with libcrypto (man pages says random crashing could occur
without them). So setting them to NULL could cause random crashing which is
even worse than what&#x
Sean Soria added the comment:
For an app that makes use of SSL itself it better set the callbacks before
spawning threads or it's going to be in trouble anyway. For an app not making
use of SSL my patch doesn't make the situation any worse. That sounds like an
overall
Sean Soria added the comment:
Yea, I've given up on getting this fixed based on the crash. Now I'm going for
it not being thread safe.
--
___
Python tracker
<http://bugs.python.
Sean Soria added the comment:
Okay, what if I attack this problem from a "it's not thread-safe" point of
view? If the callbacks are already loaded, then who knows what state the locks
are in. If you replace the locking_callback while a thread already has the
lock, and another
Sean Soria added the comment:
You've got init_* that Python calls whenever it loads a library, you could just
as easily have destroy_*. But that would probably be overkill.
How would the application know that Python has created callbacks? This is just
one instance. Who knows where else
Sean Soria added the comment:
The issue was debugged on AMD64 Linux, but I was seeing similar crashing on OSX
but could not debug because I wasn't getting a proper stack trace (probably
because something else was being loaded into that memory space). I have yet to
test if not setting
Sean Soria added the comment:
Because Python is not cleaning up after itself. I don't see how a
multi-threaded app could work around this issue. The only solution I can think
of at the app level is to reset those callbacks once python exits, but a
different thread could call an SSL fun
New submission from Sean Soria :
I seem to have a rather unique setup that causes this crash to be 100%
reproducible. My application embeds python in order to execute user code. It is
constantly loading and unloading the libraries so that they're only in memory
during execution of user
