QuinceyMorris wrote:
A bus error crash is kinda old-school. I mean it's a fairly low-level crash (dereferencing invalid pointers usually produces a more controlled, or at least better reported, crash), and that may indicate it's happening in (say) a sensitive section of the kernel. If your problem wasn't happening on multiple Macs, I'd begin to suspect a hardware fault.
That is, IMO, quite misleading. Let’s break this down:
This message:
$ ./MyTestTool
Segmentation fault: 11
means that your program has died due to an unhandled
SIGSEGV
signal. In contrast, this message:
$ ./MyTestTool
Bus error: 10
means that your program has died due to an unhandled
SIGBUS
signal.
The difference between
SIGSEGV
and
SIGBUS
is a subtle one. In the general case there’s very little difference; they both mean that the CPU has taken a memory access exception (this is a machine exception, unrelated to language exceptions like you see in Objective-C, C++ and, if you squint, Swift), and the actual signal you get is both OS and hardware related.
However, on Apple platforms the difference is actually pretty clear. You get a
SIGSEGV
when you access unmapped memory and you get a
SIGBUS
when you access memory that’s mapped but whose protection isn’t compatible with your access. For example, this code:
int main(int argc, const char * argv[]) {
* (int *) 12345 += 1;
return 0;
}
generates a
SIGSEGV
while this code:
#include <sys/mman.h>
#include <stdlib.h>
int main(int argc, const char * argv[]) {
void * m = valloc(16);
(void) mprotect(m, 16, PROT_READ);
* (int *) m += 1;
return 0;
}
generates a
SIGBUS
.
Note Two things:
I’m using C because it’s easy to get C to crash (-:
The above is a simplification. There are, for example, cases where the kernel turns what would be a
SIGBUS
into a SIGSEGV
(like overflowing your stack). However, it’s good enough for this discussion.
pf1019 wrote:
There is no crash report (in
/Users/***/Library/Logs/CrashReporter
).
That’s not the right place to look for a crash that originated on your Mac. You should, instead, look in
/Users/***/Library/Logs/DiagnosticReports/
. On my machine it contains plenty of crash logs generated while I tested the above code, and one of those clearly shows the
SIGBUS
.
$ ls /Users/quinn/Library/Logs/DiagnosticReports
…
MyTestTool_2017-01-19-094352_Sully.crash
MyTestTool_2017-01-19-094459_Sully.crash
MyTestTool_2017-01-19-094840_Sully.crash
MyTestTool_2017-01-19-095539_Sully.crash
MyTestTool_2017-01-19-095938_Sully.crash
MyTestTool_2017-01-19-100102_Sully.crash
…
$ head -n 26 /Users/quinn/Library/Logs/DiagnosticReports/MyTestTool_2017-01-19-095938_Sully.crash
Process: MyTestTool [25442]
Path: /Users/USER/Desktop/*/MyTestTool
Identifier: MyTestTool
Version: 0
Code Type: X86-64 (Native)
Parent Process: bash [25292]
Responsible: MyTestTool [25442]
User ID: 2000
Date/Time: 2017-01-19 09:59:37.961 +0000
OS Version: Mac OS X 10.12.2 (16C67)
Report Version: 12
Anonymous UUID: B9B7800F-9CC9-88EA-6DDE-8CF9BA759AB9
Sleep/Wake UUID: FA8CA4EA-6A88-4F7B-9208-A8B7B5ABC575
Time Awake Since Boot: 150000 seconds
Time Since Wake: 5700 seconds
System Integrity Protection: enabled
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00007fa372003000
Exception Note: EXC_CORPSE_NOTIFY
$
Please grab an example crash log and post that. Without that we’re all just thrashing around in the dark.
Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"
