(Actually, Debian unstable; it's missing from the platform list.) 10:14pm glenn@zewt/2 [~/stepmania] valgrind ./stepmania ==24866== Memcheck, a memory error detector for x86-linux. ==24866== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward. ==24866== Using valgrind-2.1.1, a program supervision framework for x86-linux. ==24866== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward. ==24866== For more details, rerun with: -v ==24866== ==24866== valgrind's libpthread.so: UNIMPLEMENTED FUNCTION: pthread_mutex_timedlock ==24866== valgrind's libpthread.so: unimplemented function Please report this bug at: valgrind.kde.org ==24866== Invalid read of size 4 ==24866== at 0x3C2AF67A: __res_state (vg_libpthread.c:1992) ==24866== by 0x3C547F0E: res_thread_freeres (res_init.c:572) ==24866== by 0x3C547B84: __GI___libc_freeres (set-freeres.c:49) ==24866== by 0x3C01AB9E: __vgInject___libc_freeres_wrapper (vg_intercept.c:77) ==24866== Address 0x0 is not stack'd, malloc'd or free'd ==24866== ==24866== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==24866== Access not within mapped region at address 0x0 ==24866== at 0x3C2AF67A: __res_state (vg_libpthread.c:1992) ==24866== by 0x3C547F0E: res_thread_freeres (res_init.c:572) ==24866== by 0x3C547B84: __GI___libc_freeres (set-freeres.c:49) ==24866== by 0x3C01AB9E: __vgInject___libc_freeres_wrapper (vg_intercept.c:77) ==24866== ==24866== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 61 from 1) ==24866== malloc/free: in use at exit: 667043 bytes in 22 blocks. ==24866== malloc/free: 22 allocs, 0 frees, 667043 bytes allocated. ==24866== For a detailed leak analysis, rerun with: --leak-check=yes ==24866== For counts of detected errors, rerun with: -v zsh: 24866 segmentation fault valgrind ./stepmania
*** Bug 89592 has been marked as a duplicate of this bug. ***
Created attachment 7678 [details] Patch to implement pthread_mutex_timedlock This patch implemented pthread_mutex_timedlock in valgrind's pthreads library.
I tried the patch against CVS HEAD, and it looks like I'm getting a timeout on every call to pthread_mutex_timedlock() when in fact the lock should succeed without delay.
It seems to work fine for me - can you construct a simple test case? or post the output of valgrind when run with --trace-pthread=all --trace-sched=yes?
Created attachment 7698 [details] Testprogramm for incorrect timing. The calculation of ms_end is incorrect (for huge timeouts there is a overflow). The same as in bug 76845 (http://bugs.kde.org/show_bug.cgi?id=76845) with pthread_cond_timedwait(). Or use the attached testprogramm with the following commandline (should give a timeout of 4294968 seconds): time valgrind --tool=none ./a.out 4294968 100 ==7193== Nulgrind, a binary JIT-compiler for x86-linux. ==7193== Copyright (C) 2002-2004, and GNU GPL'd, by Nicholas Nethercote. ==7193== Using valgrind-2.3.0.CVS, a program supervision framework for x86-linux. ==7193== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. ==7193== For more details, rerun with: -v ==7193== ==7193== real 0m0.904s user 0m0.160s sys 0m0.000s
Created attachment 7700 [details] Improved patch to implement pthread_mutex_timedlock Improved Tom Hughes previous patch: - fix timeout calculation (according to patch for bug 76845) - fix delta calculation in vg_scheduler.c (according to patch for bug 76845)
Thanks, but I'd rather not confuse this bug by bringing the issue of long timeouts into it - that is still pending further review by Jeremy if I'm reading the other bug correctly.
There has been no more feedback regarding this patch and it seems to work for me so I have committed my original patch. If anybody does find a problem with it timing out when it shouldn't then please open a new bug. As far as the long timeout issue goes I'm going to go and have a look at that bug now and see what I can do about commiting a fix for both condition variables and mutexes.
*** Bug 94369 has been marked as a duplicate of this bug. ***