Bug 199681

Summary:	none/tests/async-sigs fails on OS X
Product:	[Developer tools] valgrind	Reporter:	Timur Iskhodzhanov <timurrrr>
Component:	general	Assignee:	Rhys Kidd <rhyskidd>
Status:	CONFIRMED ---
Severity:	crash	CC:	dank, glider, njn, pjfloyd, rhyskidd
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Compiled Sources
OS:	macOS
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Timur Iskhodzhanov 2009-07-10 17:00:26 UTC

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.

Comment 1 Nicholas Nethercote 2009-07-14 03:23:52 UTC

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.

Comment 2 Rhys Kidd 2015-06-08 11:47:19 UTC

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