> On 29 Sep 2015, at 5:10 am, 'Lukasz Szajkowski' via modwsgi > <[email protected]> wrote: > > The actual stack trace while hanging is > #0 0x00007f047ff099b0 in sem_wait () from /lib64/libpthread.so.0 > #1 0x00007f0474b4c6d8 in PyThread_acquire_lock_timed () from > /opt/rh/python33/root/usr/lib64/libpython3.3m.so.1.0 > #2 0x00007f0474b2cab5 in _PyImport_AcquireLock () from > /opt/rh/python33/root/usr/lib64/libpython3.3m.so.1.0 > #3 0x00007f0474b2cf49 in PyImport_ImportModuleLevelObject () from > /opt/rh/python33/root/usr/lib64/libpython3.3m.so.1.0 > #4 0x00007f0474b10f8f in ?? () from > /opt/rh/python33/root/usr/lib64/libpython3.3m.so.1.0 > #5 0x00007f0474b1baa4 in PyEval_EvalFrameEx () from > /opt/rh/python33/root/usr/lib64/libpython3.3m.so.1.0 > #6 0x00007f0474b1b0f9 in PyEval_EvalFrameEx () from > /opt/rh/python33/root/usr/lib64/libpython3.3m.so.1.0 > #7 0x00007f0474b1c457 in PyEval_EvalCodeEx () from > /opt/rh/python33/root/usr/lib64/libpython3.3m.so.1.0 > #8 0x00007f0474b1aead in PyEval_EvalFrameEx () from > /opt/rh/python33/root/usr/lib64/libpython3.3m.so.1.0 > #9 0x00007f0474b1b0f9 in PyEval_EvalFrameEx () from > /opt/rh/python33/root/usr/lib64/libpython3.3m.so.1.0 > #10 0x00007f0474b1b0f9 in PyEval_EvalFrameEx () from > /opt/rh/python33/root/usr/lib64/libpython3.3m.so.1.0 > #11 0x00007f0474b1b0f9 in PyEval_EvalFrameEx () from > /opt/rh/python33/root/usr/lib64/libpython3.3m.so.1.0 > #12 0x00007f0474b1b0f9 in PyEval_EvalFrameEx () from > /opt/rh/python33/root/usr/lib64/libpython3.3m.so.1.0 > #13 0x00007f0474b1b0f9 in PyEval_EvalFrameEx () from > /opt/rh/python33/root/usr/lib64/libpython3.3m.so.1.0 > #14 0x00007f0474b1b0f9 in PyEval_EvalFrameEx () from > /opt/rh/python33/root/usr/lib64/libpython3.3m.so.1.0 > #15 0x00007f0474b1c457 in PyEval_EvalCodeEx () from > /opt/rh/python33/root/usr/lib64/libpython3.3m.so.1.0 > #16 0x00007f0474a90842 in ?? () from > /opt/rh/python33/root/usr/lib64/libpython3.3m.so.1.0 > #17 0x00007f0474a69fd6 in PyObject_Call () from > /opt/rh/python33/root/usr/lib64/libpython3.3m.so.1.0 > #18 0x00007f0474b11763 in PyEval_CallObjectWithKeywords () from > /opt/rh/python33/root/usr/lib64/libpython3.3m.so.1.0 > #19 0x00007f0474e8f6ac in ?? () from > /opt/rh/httpd24/root/etc/httpd/modules/mod_python33-wsgi.so > #20 0x00007f0474e93f8b in ?? () from > /opt/rh/httpd24/root/etc/httpd/modules/mod_python33-wsgi.so > #21 0x00007f0474e976c8 in ?? () from > /opt/rh/httpd24/root/etc/httpd/modules/mod_python33-wsgi.so > #22 0x00007f047ff03a51 in start_thread () from /lib64/libpthread.so.0 > #23 0x00007f047fc509ad in clone () from /lib64/libc.so.6
FWIW, this stack trace possibly indicates that the problem is caused by a thread being created as a side effect of a module import and where code at global scope within the module is for some reason waiting on that thread created to do something before continuing. This can cause a problem where the thread created triggers additional module imports due to function level module imports. These will block as the parent thread which did the first module import still holds the global Python module import lock. I would suggest you add in a monitor to allow you to get the actual Python stack traces as described in: * https://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Extracting_Python_Stack_Traces <https://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Extracting_Python_Stack_Traces> The Python stack traces may reveal whether this is the case, or otherwise simply tell you where the code may be dead locking. Graham -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
