Message73649
I'm not sure this is python's bug or cygwin's bug, thread enabled python
crashes thread related tests on cygwin. (ex: test_exit on test_sys.py,
test_threading.py etc)
After some investigation, I found following workaround solves this crash.
Index: Modules/_ssl.c
===================================================================
--- Modules/_ssl.c (revision 66562)
+++ Modules/_ssl.c (working copy)
@@ -1580,7 +1580,7 @@
/* Init OpenSSL */
SSL_load_error_strings();
-#ifdef WITH_THREAD
+#if defined(WITH_THREAD) && !defined(__CYGWIN__)
/* note that this will start threading if not already started */
if (!_setup_ssl_threads()) {
return;
So I applied following patch. (after reverted above workaround)
Index: Modules/_ssl.c
===================================================================
--- Modules/_ssl.c (revision 66562)
+++ Modules/_ssl.c (working copy)
@@ -1517,6 +1517,8 @@
lock. They can be useful for debugging.
*/
+ printf("-------> %d (%u) %s %d: %ul\n", n, mode & CRYPTO_LOCK,
file, line, PyThread_get_thread_ident());
+
if ((_ssl_locks == NULL) ||
(n < 0) || ((unsigned)n >= _ssl_locks_count))
return;
And this is result.
-------> 20 (1) mem_dbg.c 161: 6684680l
-------> 20 (0) mem_dbg.c 221: 6684680l
-------> 20 (1) mem_dbg.c 161: 6684680l
-------> 20 (0) mem_dbg.c 221: 6684680l
-------> 16 (1) ssl_ciph.c 273: 6684680l
-------> 16 (0) ssl_ciph.c 276: 6684680l
-------> 16 (1) ssl_ciph.c 277: 6684680l
-------> 20 (1) mem_dbg.c 161: 6684680l
-------> 20 (0) mem_dbg.c 221: 6684680l
-------> 20 (1) mem_dbg.c 161: 6684680l
-------> 20 (0) mem_dbg.c 221: 6684680l
-------> 16 (0) ssl_ciph.c 308: 6684680l
started worker thread
trying nonsensical thread id
waiting for worker thread to get started
verifying worker hasn't exited
attempting to raise asynch exception in worker
waiting for worker to say it caught the exception
-------> 1 (1) err.c 418: 7282896l
all OK -- joining worker
-------> 1 (1) err.c 418: 7282896l
6020 [unknown (0x650)] python 1156 _cygtls::handle_exceptions: Error
while du
mping state (probably corrupted stack)
Illegal instruction (core dumped)
Thread 7282896l tries to lock same object twice. I'm not familiar with
OpenSSL nor Python Thread, so I cannot fix this.
# Can callback function for CRYPTO_set_locking_callback() be called like
this? How does PyThread_allocate_lock behave in this situation? I don't
know.
I used OpenSSL0.9.8h installed via cygwin setup. |
|
Date |
User |
Action |
Args |
2008-09-23 16:55:48 | ocean-city | set | recipients:
+ ocean-city |
2008-09-23 16:55:47 | ocean-city | set | messageid: <1222188947.11.0.23414335781.issue3947@psf.upfronthosting.co.za> |
2008-09-23 16:55:45 | ocean-city | link | issue3947 messages |
2008-09-23 16:55:44 | ocean-city | create | |
|