When a process running with valgrind (3.7, 3.8, 3.9), it hangs in pthread_spin_lock function. #include <stdio.h> #include <stdlib.h> #include <pthread.h> #include <iostream> #include <sys/types.h> #include <linux/unistd.h> using namespace std; void *print_message_function( void *ptr ); pthread_spinlock_t spinlock; int giValue = 0; int main() { pthread_spin_init(&spinlock, NULL); pthread_t thread1, thread2; pthread_create( &thread1, NULL, print_message_function, NULL); pthread_create( &thread2, NULL, print_message_function, NULL); pthread_join( thread1, NULL); pthread_join( thread2, NULL); return EXIT_SUCCESS; }; void *print_message_function(void *ptr) { for (int i = 0 ; i < 10000 ; i++) { pthread_spin_lock(&spinlock); giValue++; cout << giValue << endl; pthread_spin_unlock(&spinlock); } }; Reproducible: Always Steps to Reproduce: 1. Copy the code into main.cpp 2. g++ -lpthread main.cpp 3. valgrind ./a.out Actual Results: It runs upto 4, 5 iterations. 1 2 3 4 5 Expected Results: It should go upto 20000 The test was done in SUSE Enterprice Server 11 uname -a Linux exch-103 3.0.74-0.6.10-default #1 SMP Fri May 24 09:05:40 UTC 2013 (590b33a) x86_64 x86_64 x86_64 GNU/Linux
Try with --fair-sched=yes.
Thanks Julian for the response. It behaves the same even with --fair-sched=yes as well.
I can reproduce that. Hmm. Even with an unfair scheduling, one thread should progress. As running with callgrind, the code worked, I tried with "--vex-guest-chase-thresh=0". That works, too... With "--vex-guest-chase-thresh=1" it hangs again. The loop in the spinlock is simple: loop: pause cmpl $0x0, ($rdi) jg out jmp loop Josef
I can replicate this against current valgrind svn. A -v -v --trace-sched=yes run ends with: --22512-- SCHED[2]: acquired lock (VG_(client_syscall)[async]) --22512-- SCHED[2]: TRC: SYSCALL --22512-- SCHED[2]: releasing lock (VG_(client_syscall)[async]) -> VgTs_WaitSys 8 --22512-- SCHED[2]: acquired lock (VG_(client_syscall)[async]) --22512-- SCHED[2]: TRC: SYSCALL --22512-- SCHED[2]: releasing lock (VG_(client_syscall)[async]) -> VgTs_WaitSys 9 --22512-- SCHED[3]: acquired lock (thread_wrapper(starting new thread)) --22512-- SCHED[3]: entering VG_(scheduler) --22512-- SCHED[3]: TRC: SYSCALL --22512-- SCHED[3]: TRC: CHAIN_ME_FAST --22512-- SCHED[3]: TRC: YIELD --22512-- SCHED[3]: TRC: FASTMISS --22512-- SCHED[3]: TRC: CHAIN_ME_FAST --22512-- SCHED[3]: TRC: YIELD --22512-- SCHED[3]: TRC: YIELD --22512-- SCHED[3]: TRC: YIELD --22512-- SCHED[3]: TRC: YIELD --22512-- SCHED[3]: TRC: YIELD --22512-- SCHED[3]: TRC: YIELD --22512-- SCHED[3]: TRC: YIELD --22512-- SCHED[3]: TRC: YIELD --22512-- SCHED[3]: TRC: YIELD --22512-- SCHED[3]: TRC: YIELD --22512-- SCHED[3]: TRC: YIELD --22512-- SCHED[3]: TRC: YIELD --22512-- SCHED[3]: TRC: YIELD --22512-- SCHED[3]: TRC: YIELD --22512-- SCHED[3]: TRC: YIELD --22512-- SCHED[3]: TRC: YIELD --22512-- SCHED[3]: TRC: YIELD --22512-- SCHED[3]: TRC: YIELD --22512-- SCHED[3]: TRC: YIELD --22512-- SCHED[3]: TRC: YIELD --22512-- SCHED[3]: TRC: YIELD --22512-- SCHED[3]: TRC: YIELD --22512-- SCHED[3]: TRC: YIELD [... repeated forever ...]
And indeed using vex-guest-chase-thresh=0 makes it work.
I can also reproduce this. This is totally bizarre. Investigating.
Fixed, r14386.
This is ok now. Tested in 3.10 beta path.
*** Bug 339537 has been marked as a duplicate of this bug. ***