blocked on futex

[Aahz]

In article <5cffe00b-2cd3-45dc-a674-87466e8ffb48 at f19g2000vbf.googlegroups.com>,
msoulier  <msoulier at digitaltorque.ca> wrote:
>On Mar 20, 10:22=A0am, a... at pythoncraft.com (Aahz) wrote:
>> 
>> Have you tried dumping core and using gdb to find out more about the
>> process state?
>
>Yeah, just did. I need the debuginfo for proper symbols, but here's an
>initial backtrace.
>
>#0  0x0084d7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
>#1  0x009dbc1f in sem_wait at GLIBC_2.0 () from /lib/tls/libpthread.so.0
>#2  0x00a7ce1e in PyThread_acquire_lock () from /usr/lib/
>libpython2.3.so.1.0
>#3  0x00a7ff07 in _PyObject_GC_Del () from /usr/lib/libpython2.3.so.
>1.0
>#4  0x00a29991 in PyCFunction_Call () from /usr/lib/libpython2.3.so.
>1.0
>#5  0x00a5c51c in _PyEval_SliceIndex () from /usr/lib/libpython2.3.so.
>1.0

   [...]

>#53 0x00a5d98b in _PyEval_SliceIndex () from /usr/lib/libpython2.3.so.
>1.0
>#54 0x00a5e0a6 in PyEval_EvalCodeEx () from /usr/lib/libpython2.3.so.
>1.0
>#55 0x00a5e36d in PyEval_EvalCode () from /usr/lib/libpython2.3.so.1.0
>#56 0x00a77827 in PyErr_Display () from /usr/lib/libpython2.3.so.1.0
>#57 0x00a78952 in PyRun_SimpleFileExFlags () from /usr/lib/
>libpython2.3.so.1.0
>#58 0x00a799a4 in PyRun_AnyFileExFlags () from /usr/lib/
>libpython2.3.so.1.0
>#59 0x00a7e69e in Py_Main () from /usr/lib/libpython2.3.so.1.0
>#60 0x080485b2 in main ()
>
>It looks to me like it's blocking in pthread_mutex_lock, synchronizing
>on a critical section for thread safety. Looks like a bug to me. I
>went to report it, but there's no 2.3 version in the python bug
>tracker so I'm assuming it's no longer supported.

That's a bit bizarre.  You're correct that if this is a Python bug, there
will be no fixes available.  However, you said earlier that this is a
patched Python, so I'm wondering whether the applied patch is broken.
Assuming I'm reading this correctly, it's hanging when trying to emit a
top-level exception using PyErr_Display.

At this point, I would continue watching core dumps and seeing whether
_PyObject_GC_Del and/or PyErr_Display are always in the stack trace.
You might also write your own top-level exception handler that logs to a
file.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"At Resolver we've found it useful to short-circuit any doubt and just
refer to comments in code as 'lies'. :-)"
--Michael Foord paraphrases Christian Muirhead on python-dev, 2009-3-22