This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author dmalcolm
Recipients David.Edelsohn, dmalcolm
Date 2013-04-24.19:40:29
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1366832429.83.0.0392919408442.issue17833@psf.upfronthosting.co.za>
In-reply-to
Content
Looking at test_gdb.out, the issue is that the threads waiting for the GIL have e.g. this at the top of their backtrace:

Thread 2 (Thread 0x3fffb14af200 (LWP 37119)):
#0  0x0000008075181ea8 in __pthread_cond_timedwait (cond=0x103ea140 <gil_cond>, mutex=0x103ea170 <gil_mutex>, abstime=0x3fffb14abf68) at pthread_cond_timedwait.c:167
#1  0x00000000100f59f8 in PyCOND_TIMEDWAIT (cond=0x103ea140 <gil_cond>, mut=0x103ea170 <gil_mutex>, us=5000) at /home/dje/src/cpython/Python/condvar.h:103
#2  0x00000000100f5ffc in take_gil (tstate=0x1043b020) at /home/dje/src/cpython/Python/ceval_gil.h:224

i.e. the topmost frame has name "__pthread_cond_timedwait" (two leading underscores.

However, the gdb hooks (in Tools/gdb/libpython.py) have:

    def is_waiting_for_gil(self):
        '''Is this frame waiting on the GIL?'''
        # This assumes the _POSIX_THREADS version of Python/ceval_gil.h:
        name = self._gdbframe.name()
        if name:
            return name.startswith('pthread_cond_timedwait')

i.e. no underscores, hence that name.startswith conditional doesn't match.
History
Date User Action Args
2013-04-24 19:40:29dmalcolmsetrecipients: + dmalcolm, David.Edelsohn
2013-04-24 19:40:29dmalcolmsetmessageid: <1366832429.83.0.0392919408442.issue17833@psf.upfronthosting.co.za>
2013-04-24 19:40:29dmalcolmlinkissue17833 messages
2013-04-24 19:40:29dmalcolmcreate