Re: [Valgrind-users] Bug in libpthread: sem_wait succeeded on semaphore without prior sem_post

[Paul M. <pa...@fl...>]

Julian Seward <jseward <at> acm.org> writes:

> 
> 
> > How reliable is Helgrind's log message mentioned in the subject?
> 
> Well, it's probably not _completely_ broken, since I did go to
> some effort to test it, and IIRC the regression tests test it too.

:)
I wasn't suggesting anything of that kind.
 
> > Are there any known versions of libpthread that are broken?
> 
> libpthread in general seems fairly reliable to me.
> 
> So what's the apparently-anomalous behaviour you are seeing?

Well, during testing of a multiprocessing module in Python that was locking up I
decided to run the failing test case under helgrind. The message about the
libpthread bug is the first thing reported, followed by a failing assertion.
This is with the helgrind development version from
svn://svn.valgrind.org/valgrind/branches/HGDEV, by the way (whose existence I
found in a libpthread-related bug report):

==336== Thread #1 is the program's root thread
==336==
==336== Thread #1: Bug in libpthread: sem_wait succeeded on semaphore without
prior sem_post
==336==    at 0x40083C1: sem_wait_WRK (hg_intercepts.c:1092)
==336==    by 0x400846A: sem_wait@* (hg_intercepts.c:1110)
==336==    by 0x46A0F6B: semlock_acquire (semaphore.c:310)
==336==    by 0x808BF39: PyEval_EvalFrameEx (ceval.c:3359)
==336==    by 0x808D0AA: PyEval_EvalCodeEx (ceval.c:2798)
==336==    by 0x808B95E: PyEval_EvalFrameEx (ceval.c:3457)
==336==    by 0x808D0AA: PyEval_EvalCodeEx (ceval.c:2798)
==336==    by 0x80F4E05: function_call (funcobject.c:628)
==336==    by 0x80D14CB: PyObject_Call (abstract.c:2178)
==336==    by 0x808A0CD: PyEval_EvalFrameEx (ceval.c:3660)
==336==    by 0x808BFC1: PyEval_EvalFrameEx (ceval.c:3447)
==336==    by 0x808BFC1: PyEval_EvalFrameEx (ceval.c:3447)

Helgrind: hg_main.c:6327 (evh__pre_thread_ll_create): Assertion 'thr_c == NULL'
failed.
==348==    at 0x3801B579: report_and_quit (m_libcassert.c:140)
==348==    by 0x3801B3ED: vgPlain_assert_fail (m_libcassert.c:205)
==348==    by 0x38010575: evh__pre_thread_ll_create (hg_main.c:6327)
==348==    by 0x3806B8A0: vgSysWrap_x86_linux_sys_clone_before
(syswrap-x86-linux.c:292)
==348==    by 0x380364BF: vgPlain_client_syscall (syswrap-main.c:850)
==348==    by 0x38034E05: vgPlain_scheduler (scheduler.c:798)
==348==    by 0x38037707: run_a_thread_NORETURN (syswrap-linux.c:89)

Now I know Python isn't the nicest thing to run valgrind on, at least with
memcheck, due to Python's internal memory management doing all sorts of crazy
tricks. I wondered wether something similar would apply to helgrind and Python.

Regards,
Paul