Created attachment 41064 [details] Short test reproducing the problem I'm getting strange assertion failures running the following test under Nullgrind on Mac OS 10.5: $ g++ bad_sigprof.cc -o bad_sigprof $ valgrind --tool=none ./bad_sigprof ... valgrind: m_syswrap/syswrap-main.c:1314 (vgPlain_client_syscall): Assertion 'sci->status.what == SsIdle' failed. ==5469== at 0xF00864ED: ??? ==5469== by 0xF00867A1: ??? ==5469== by 0xF00E5C56: ??? ==5469== by 0xF00E10A3: ??? ==5469== by 0xF00E21F9: ??? ==5469== by 0xF010893F: ??? sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==5469== at 0xF009DF2A: ??? ==5469== by 0x1F7AC2: cerror (in /usr/lib/libSystem.B.dylib) ==5469== by 0x1F15: main (in ./bad_sigprof) Thread 2: status = VgTs_Yielding ==5469== at 0x1F8035: malloc (in /usr/lib/libSystem.B.dylib) ==5469== by 0x228154: _pthread_start (in /usr/lib/libSystem.B.dylib) ==5469== by 0x228011: thread_start (in /usr/lib/libSystem.B.dylib) Thread 3: status = VgTs_Yielding ==5469== at 0xFFFF0260: ??? ==5469== by 0x1FD38C: free (in /usr/lib/libSystem.B.dylib) ==5469== by 0x1DDE: Worker() (in ./bad_sigprof) ==5469== by 0x228154: _pthread_start (in /usr/lib/libSystem.B.dylib) ==5469== by 0x228011: thread_start (in /usr/lib/libSystem.B.dylib) Is there something wrong with the test or it's an error? NB: ThreadSanitizer (code.google.com/p/data-race-test) consumes very much memory on a similar test. Could it be due to repeated translation of the signal handler?
I've just seen the same assertion on Linux
Created attachment 43487 [details] output related to assertion On Mac OS X 10.5.8 (9L30), Revision: 11127. I started firefox + an extension with --trace-children=yes and did not see the assertion. Then I added --smc-check=all and did see the assertion. Starting firefox again without an extension with --smc-check=all didn't show it nor did subsequent attempts with firefox + extension.
On OS X 10.10 and Valgrind SVN trunk I am only seeing the below output without the assertion. Would be great if you could reconfirm on your OS X 10.5 system with latest Valgrind SVN trunk that it still occurs, to move orthogonally through the problem space: $ ./vg-in-place --tool=none ~/Downloads/bad_sigprof ==99266== Nulgrind, the minimal Valgrind tool ==99266== Copyright (C) 2002-2013, and GNU GPL'd, by Nicholas Nethercote. ==99266== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for copyright info ==99266== Command: /Users/rhyskidd/Downloads/bad_sigprof ==99266== GLOB=0 ==99266==
I'll also add this reproducer to the test suite, so we can be more likely to see the assert if still present on certain systems.
This can now be reproducibly be tested with: $ perl tests/vg_regtest none/tests/darwin/bug228343 bug228343: valgrind -q --tool=none ./bug228343 == 1 test, 0 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == (Strictly speaking, I should also amend that test so that it fails for GLOB=0, however that is a separate issue).
This is failing on the latest macOs we can build for, 10.13
$ perl tests/vg_regtest none/tests/darwin/bug228343 bug228343: valgrind -q --tool=none ./bug228343 sh: line 1: 334 Segmentation fault: 11 VALGRIND_LIB=/Users/paulf/scratch/valgrind/.in_place VALGRIND_LIB_INNER=/Users/paulf/scratch/valgrind/.in_place /Users/paulf/scratch/valgrind/./coregrind/valgrind --command-line-only=yes --memcheck:leak-check=no --tool=none -q --tool=none ./bug228343 > bug228343.stdout.out 2> bug228343.stderr.out *** bug228343 failed (stdout) *** *** bug228343 failed (stderr) *** == 1 test, 1 stderr failure, 1 stdout failure, 0 stderrB failures, 0 stdoutB failures, 0 post failures == none/tests/darwin/bug228343 (stdout) none/tests/darwin/bug228343 (stderr) $ ../../../vg-in-place --tool=none ./bug228343 ==371== Nulgrind, the minimal Valgrind tool ==371== Copyright (C) 2002-2017, and GNU GPL'd, by Nicholas Nethercote. ==371== Using Valgrind-3.23.0.GIT and LibVEX; rerun with -h for copyright info ==371== Command: ./bug228343 ==371== ==371== ==371== Process terminating with default action of signal 11 (SIGSEGV) ==371== Access not within mapped region at address 0x18 ==371== at 0x1006545BA: _pthread_body (in /usr/lib/system/libsystem_pthread.dylib) ==371== by 0x10065450C: _pthread_start (in /usr/lib/system/libsystem_pthread.dylib) ==371== by 0x100653BF8: thread_start (in /usr/lib/system/libsystem_pthread.dylib) ==371== If you believe this happened as a result of a stack ==371== overflow in your program's main thread (unlikely but ==371== possible), you can try to increase the size of the ==371== main thread stack using the --main-stacksize= flag. ==371== The main thread stack size used in this run was 8388608.