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.
At the moment this test seems to hang. With Louis Brunner's repo on OSX 10.13 I get cat none/tests/darwin/bug228343*diff --- bug228343.stderr.exp 2024-05-22 08:31:10.000000000 +0200 +++ bug228343.stderr.out 2025-11-15 16:21:03.000000000 +0100 @@ -0,0 +1,2 @@ +UNKNOWN Mach port modified (port 0x........ delta -2147483648) +UNKNOWN Mach port modified (port 0x........ delta -2147483648) --- bug228343.stdout.exp 2024-05-22 08:31:10.000000000 +0200 +++ bug228343.stdout.out 2025-11-15 16:21:03.000000000 +0100 @@ -1 +1 @@ - GLOB=0 + GLOB=708 The GLOB looks plausible. Running outside of Valgrind I get a much higher value. The test is fairly slow.
commit bf7c22738b4ba6ad72615c66f3a65bda530843cb (HEAD -> master, origin/master, origin/HEAD) Author: Paul Floyd <pjfloyd@wanadoo.fr> Date: Thu Nov 27 07:22:18 2025 +0100 Darwin: many fixes for OSX 10.13 Most of these changes are from Louis Brunner's GitHub repo. The most imortant changes are to the memory space and to the code related to getting the host filename during startup. This means that when Valgrind crashes or hits an assert we now get a legible host stacktrrace. This also fixes none/tests/darwin/bug228343