|
From: Paul M. <pa...@fl...> - 2008-06-13 15:15:01
|
Hello, How reliable is Helgrind's log message mentioned in the subject? Are there any known versions of libpthread that are broken? Regards, Paul |
|
From: Julian S. <js...@ac...> - 2008-06-13 15:27:04
|
> 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. > 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? J |
|
From: Paul M. <pa...@fl...> - 2008-06-13 15:41:16
|
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 |
|
From: Paul W. <pa...@bl...> - 2008-06-13 22:33:25
|
On Fri, Jun 13, 2008 at 03:41:12PM +0000, Paul Melis wrote: > ==336== Thread #1: Bug in libpthread: sem_wait succeeded on semaphore without > prior sem_post Probably a silly question, but I guess Helgrind does take into account that semaphores can be created with a non-zero count...? -- Paul We have a number of doors that declare "This door is alarmed" but it's not immediately obvious what is scaring them.. -- Geoff Lane |
|
From: Konstantin S. <kon...@gm...> - 2008-06-16 07:45:32
|
> 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): Does the Helgrind from 3.3.1 fail? HGDEV has a bit different sem_wait handling (added support for sem_trywait), which could be the reason. Could you suggest a way to reproduce? --kcc > > ==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 > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Paul M. <pa...@fl...> - 2008-06-14 17:07:52
|
Paul Walker <paul <at> blacksun.org.uk> writes: > > On Fri, Jun 13, 2008 at 03:41:12PM +0000, Paul Melis wrote: > > > ==336== Thread #1: Bug in libpthread: sem_wait succeeded on semaphore without > > prior sem_post > > Probably a silly question, but I guess Helgrind does take into account that > semaphores can be created with a non-zero count...? > Yes, this seems to have been fixed some time ago, see the thread http://thread.gmane.org/gmane.comp.debugging.valgrind/7594 Paul |
|
From: Paul M. <pa...@fl...> - 2008-06-16 08:04:05
|
Konstantin Serebryany <konstantin.s.serebryany <at> gmail.com> writes: > > svn://svn.valgrind.org/valgrind/branches/HGDEV, by the way > (whose existence I found in a libpthread-related bug report): > > Does the Helgrind from 3.3.1 fail? Well, it does also happen with 3.3.0. I'll try with 3.3.1 > HGDEV has a bit different sem_wait handling (added support for > sem_trywait), which could be the reason. > Could you suggest a way to reproduce? I'm afraid that would be hard, as the code exposing this isn't written by me and I'm also not really familiar with it. It would take me a long time to reduce this to a simple reproduction. Paul |
|
From: Konstantin S. <kon...@gm...> - 2008-06-16 08:05:09
|
On Mon, Jun 16, 2008 at 12:03 PM, Paul Melis <pa...@fl...> wrote: > Konstantin Serebryany <konstantin.s.serebryany <at> gmail.com> writes: > >> > svn://svn.valgrind.org/valgrind/branches/HGDEV, by the way >> (whose existence I found in a libpthread-related bug report): >> >> Does the Helgrind from 3.3.1 fail? > > Well, it does also happen with 3.3.0. I'll try with 3.3.1 > >> HGDEV has a bit different sem_wait handling (added support for >> sem_trywait), which could be the reason. >> Could you suggest a way to reproduce? > > I'm afraid that would be hard, as the code exposing this isn't > written by me and I'm also not really familiar with it. It would > take me a long time to reduce this to a simple reproduction. I see. I'll try to see if I can reproduce it... > > Paul > > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Paul M. <pa...@fl...> - 2008-06-16 08:12:16
|
Konstantin Serebryany <konstantin.s.serebryany <at> gmail.com> writes: > On Mon, Jun 16, 2008 at 12:03 PM, Paul Melis > <paul <at> floorball-flamingos.nl> wrote: > > Konstantin Serebryany <konstantin.s.serebryany <at> gmail.com> writes: > > > >> Does the Helgrind from 3.3.1 fail? > > > > Well, it does also happen with 3.3.0. I'll try with 3.3.1 Same with 3.3.1 Paul |
|
From: Konstantin S. <kon...@gm...> - 2008-06-17 07:21:59
|
Since 3.3.1 fails, the problem is not in sem_trywait() support... Could you please redefine TRACE_SEM_FNS in helgrind/hg_intercepts.c to 1, recompile valgrind, rerun and send us the log? On Mon, Jun 16, 2008 at 12:12 PM, Paul Melis <pa...@fl...> wrote: > Konstantin Serebryany <konstantin.s.serebryany <at> gmail.com> writes: > >> On Mon, Jun 16, 2008 at 12:03 PM, Paul Melis >> <paul <at> floorball-flamingos.nl> wrote: >> > Konstantin Serebryany <konstantin.s.serebryany <at> gmail.com> writes: >> > >> >> Does the Helgrind from 3.3.1 fail? >> > >> > Well, it does also happen with 3.3.0. I'll try with 3.3.1 > > Same with 3.3.1 > > Paul > > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |