When running my application with valgrind, the process hangs and cannot be ctrl-C'd. Removing calls to system() from my application prevents the hang. Setting --trace-children=no does not help. Reproducible: Always Steps to Reproduce: 1. Run an app which calls system(), under valgrind Actual Results: Hang Expected Results: No hang OS X 10.7.4, x86_64
Created attachment 73140 [details] Valgrind test case demonstrating the problem Log generated by R -d "valgrind --tool=none --smc-check=all --trace-syscalls=yes" --vanilla < test.R &> valgrind_R_log.dat test.R contains print(seq(10))
I also encounter this problem, encountered when I ran R 2.15.1 under valgrind 3.9.0.SVN or valgrind 3.8.0. The running process can only be terminated using SIGKILL. I am using OS X 10.6.8, x86_64 I attached the with output "--trace-syscalls=yes" above.
*** Bug 284004 has been marked as a duplicate of this bug. ***
Here's a slightly simpler test case :-) #include <stdlib.h> int main ( void ) { system("/bin/date"); return 0; } It seems that system() on Darwin calls __posix_spawn, and we wind up in PRE(posix_spawn) in coregrind/m_syswrap/syswrap-darwin.c, and the call "VG_(gdbserver) (tid);" never returns. Philippe, any idea why? In the meantime a simple workaround is simply to disable that call, as follows: Index: coregrind/m_syswrap/syswrap-darwin.c =================================================================== --- coregrind/m_syswrap/syswrap-darwin.c (revision 12864) +++ coregrind/m_syswrap/syswrap-darwin.c (working copy) @@ -2835,7 +2835,7 @@ VG_(debugLog)(1, "syswrap", "Posix_spawn of %s\n", (Char*)ARG2); // Terminate gdbserver if it is active. - if (VG_(clo_vgdb) != Vg_VgdbNo) { + if (0 && VG_(clo_vgdb) != Vg_VgdbNo) { // If the child will not be traced, we need to terminate gdbserver // to cleanup the gdbserver resources (e.g. the FIFO files). // If child will be traced, we also terminate gdbserver: the new
Should be fixed by revision 12879.
After more in depth analysis, committed another fix (revision 12882).
There was also a small followup change in r12883. Closing since this is now fixed.