| Summary: | Valgrind hangs in pthread_spin_lock consuming 100% CPU | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Sujith Gunawardhane <sujithsg> |
| Component: | general | Assignee: | Julian Seward <jseward> |
| Status: | CLOSED FIXED | ||
| Severity: | normal | CC: | josef.weidendorfer, mark, sage |
| Priority: | NOR | ||
| Version First Reported In: | 3.9.0 | ||
| Target Milestone: | --- | ||
| Platform: | RedHat Enterprise Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
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. *** |
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