https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93731
Bug ID: 93731
Summary: [10 regression] asan tests cause kernel panic on
Darwin 11
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: ro at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
iains at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at
gcc dot gnu.org,
marxin at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-apple-darwin11.4.2
Target: x86_64-apple-darwin11.4.2
Build: x86_64-apple-darwin11.4.2
Sometime after 20191101, my mainline bootstraps on Mac OS X 10.7/Darwin 11
began
to fail completely. Initially it seemed the Mac minis I've been using remotely
had just been turned off willy-nilly, but even after it had been assured that
this
wasn't the case, the machines still stopped in the middle of make check without
any indication of what had happened.
Only after I'd run such a bootstrap in a VirtualBox VM (with Mac OS X 10.7.5)
did
I see that the machines (obviously like bare metal) crashed with a kernel panic
for some asan tests (I've seen alloca_big_alignment.exe,
alloca_detect_custom_size. and bitfield-1.exe). Only asan tests seem to be
affected (I didn't try any more given the tedious nature of the failure) and
probably only 64-bit ones (I do run multilib tests on Darwin if possible).
As expected, the ubsan tests still work.
Here's the gist of the panics (I do have screen shots if need be):
panic(cpu 0 caller 0xffffff8002c4794): Kernel trap at 0xffffff800053ae2, type
14=page fault, registers:
[...]
Debugger called: <panic>
Backtrace (CPU 0),Frame : Return Address
[...] mach_kernel : _panic + 0x252
_kernel_trap + 0x6a4
_return_from_trap + 0xcd
_fdexec + 0x172
_kco_ma_addsample + 0x162c
_kco_ma_addsample + 0x2a80
_posix_spawn + 0xab6
_unix_syscall64 + 0x1fb
_hndl_unix_scall64 + 0x13
BSD process name corresponding to current thread: alloca_big_align
The obvious immediate fix is to disable libsanitizer on Darwin 11. While in
theory one could keep the 32-bit tests if it really turns out that they
continue
to work and the ubsan ones, it's probably not worth the effort given the age of
the OS version and missing provision for enabling ubsan separately.
