svn co -r 10427 svn://svn.valgrind.org/valgrind/trunk valgrind cd valgrind build mkdir NONE_TESTS g++ -o NONE_TESTS/async-sigs none/tests/async-sigs.c ./inst/bin/valgrind ./NONE_TESTS/async-sigs ... <some children die with:> ==32427== Process terminating with default action of signal 10 (SIGBUS) ==32427== Non-existent physical address at address 0xA0046A20 ==32427== at 0x252562: __sigsuspend (in /usr/lib/libSystem.B.dylib) ==32427== by 0x1BCB: test(int, int, int) (in ./NONE_TESTS/async-sigs) ==32427== by 0x1E4F: main (in ./NONE_TESTS/async-sigs) =============== Also reproducible with: ./inst/bin/valgrind --tool=none ./NONE_TESTS/async-sigs ... ==32463== Process terminating with default action of signal 10 (SIGBUS) ==32463== Non-existent physical address at address 0x75000 ==32463== at 0x1BC5: test(int, int, int) (in ./NONE_TESTS/async-sigs) ==32463== by 0x1DA7: main (in ./NONE_TESTS/async-sigs) ==32463== =============== I've seen similar crashes running Chromium tests, so I decided to find some SIGBUS reproducers. This bug happens a bit more often under ThreadSanitizer on Mac. I guess this can be somehow related to https://bugs.kde.org/show_bug.cgi?id=192634 since aspacemgr reports appear in the logs of other Chromium tests which crash on Mac.
Is this on Mac? If so, it's a known failure, due to a bug/unimplemented feature in the Darwin kernel -- the 'si_code' field is unreliable on Mac. See the comment in coregrind/m_signals.c:is_signal_from_kernel() for details. As for whether the async-sigs failure corresponds to the failure you saw -- it sends SIGBUS signals to a process from another process. It's a pretty strange test, and so your program probably isn't doing such things. So if you can find another reproducer that would help a lot.
I'll take a look at this one, although worth noting the above comments from @njn about the unreliable 'si_code' field on OS X. It can be reliably reproduced with: $ make check $ perl tests/vg_regtest none/tests/async-sigs