[issue7672] _ssl module causes segfault

Martin v. Löwis added the comment: As for the module's __del__: that is already implemented in moduleobject.c:module_dealloc. It doesn't give the module implementation a hook to execute custom code. In Py3k, you can implemenent the m_free hook of the PyModuleDef. --

[issue7672] _ssl module causes segfault

Sean Soria added the comment: You are correct, dlclose is called on libpythonXY.so and all .so modules loaded by it. -- ___ Python tracker ___ __

[issue7672] _ssl module causes segfault

Martin v. Löwis added the comment: Bill: unloading the shared probably means he does dlclose() (after having done dlopen initially). Furthermore, it probably means he does that on libpythonxy.so. I'm a bit puzzled that it also affects _ssl.so (unless he dlcloses that as well) - Python, on its

[issue7672] _ssl module causes segfault

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's there n

[issue7672] _ssl module causes segfault

Bill Janssen added the comment: Martin, I'm thinking that the module object has a __del__ method, and we could un-register the callbacks there. But I don't know if that method would ever get called. How does the act of "unloading a library" interact with the initialized Python interpreter?

[issue7672] _ssl module causes segfault

Martin v. Löwis added the comment: Bill, what do you think? -- assignee: -> janssen ___ Python tracker ___ ___ Python-bugs-list maili

[issue7672] _ssl module causes segfault

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 gain to me. --

[issue7672] _ssl module causes segfault

Martin v. Löwis added the comment: The patch is not thread-safe. If two threads where to do the same thing simultaneously, they might (simultaneously) both determine that the lock is not installed, and then one would overwrite the lock of the other, leading exactly to the situation that the p

[issue7672] _ssl module causes segfault

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 ___

[issue7672] _ssl module causes segfault

Martin v. Löwis added the comment: There is no way to unload a module, at least not until Python 3. Losing all references to the module won't help. -- ___ Python tracker ___ ___

[issue7672] _ssl module causes segfault

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 thread comes in

[issue7672] _ssl module causes segfault

Martin v. Löwis added the comment: > You you suggest that any application which > dynamically loads a library never unload it? Correct. Library unloading just don't work. Trying it anyway is an endless uphill battle. -- ___ Python tracker

[issue7672] _ssl module causes segfault

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 this i

[issue7672] _ssl module causes segfault

Martin v. Löwis added the comment: So how do you do cleanup on Linux, or on OSX, in a shared library? I'd claim that the bug is in your application. It shouldn't unload a DLL that is still in use (by having a function pointer into it stored globally). Testing for a prior pointer value may fix

[issue7672] _ssl module causes segfault

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 those fu

[issue7672] _ssl module causes segfault

Martin v. Löwis added the comment: What operating system is this on? IIUC, Python has no chance to perform any cleanup. So it's not a bug that no cleanup happens. I don't understand the proposal of not setting the callback if they are already set. If that is done, how can we be sure that the

[issue7672] _ssl module causes segfault

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 function a

[issue7672] _ssl module causes segfault

Martin v. Löwis added the comment: Why do you think this is a bug in Python? -- nosy: +loewis ___ Python tracker ___ ___ Python-bugs-l

[issue7672] _ssl module causes segfault

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 code. T