Crash reporter doesn't catch stack overflow on real device #60

Closed
kstenerud opened this Issue Oct 16, 2011 · 7 comments

Projects

None yet

3 participants

@kstenerud

The following code generates a crash report on the simulator, but NOT on a device:

- (IBAction) triggerCrash {
    [self triggerCrash];
}
@TheRealKerni
Bit Stadium GmbH member

You might want to report that to the actual PLCrashReporter repository and developer: http://code.google.com/p/plcrashreporter/

@landonf

Indeed, but, which version of PLCrashReporter is in use? PLCR has sanity-checking code that truncates reports that grow too large, as to prevent a run-away reporter from writing out a huge crash report.

There's a bug in the 2009 1.0 release that would cause PLCR to truncate the report early when a stack overflow occurred, rather than truncating the individual stack trace at a reasonable point.

However, this would manifest itself as a corrupt report (reading the report on launch would return an error), rather than no report entirely.

@TheRealKerni
Bit Stadium GmbH member

Landon, I reproduced the problem even with 1.1 Beta 1. No crash report file is being written.

@landonf

Thanks! I'll take a look

@landonf

Karl, Andreas, can you confirm which version of Xcode/compiler you used to build the PLCR binaries, or whether you used the downloadable binaries from the Google Code page?

Thanks!

@TheRealKerni
Bit Stadium GmbH member

Landon, I used the downloadable binaries.

@kstenerud

It's starting to look like this is an error in iOS itself. I tried making a simple signal handler and causing a stack overflow. The signal handler caught the signal on the simulator, but on the device it didn't trigger at all.

Looking in the xnu code in bsd/uxkern/ux_exception.c yields some interesting comments:

    /*
     * Stack overflow should result in a SIGSEGV signal
     * on the alternate stack.
     * but we have one or more guard pages after the
     * stack top, so we would get a KERN_PROTECTION_FAILURE
     * exception instead of KERN_INVALID_ADDRESS, resulting in
     * a SIGBUS signal.
     * Detect that situation and select the correct signal.
     */

My own testing confirms this behavior on the simulator. A stack overflow is caught by the signal handler as SIGSEGV with code SEGV_ACCERR.

When I run the same code on a device, the signal handler doesn't trigger, but the Apple crash handler, which hooks into the mach exception ports, reports the following:

Exception Type:  EXC_BAD_ACCESS (SIGILL)
Exception Codes: KERN_PROTECTION_FAILURE at 0x2fd00ff8

Since I don't have access to the arm-specific code, I can only conjecture at this point, but it looks like KERN_PROTECTION_FAILURE is somehow mapping to SIGILL (which seems weird since the PC is pointing to valid code inside libobjc) instead of SIGBUS, and the code in ux_exception.c checks against SIGBUS only:

    if (code[0] == KERN_PROTECTION_FAILURE &&
    ux_signal == SIGBUS) {

This would seem to be an edge case that's not handled by the BSD signal translator code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment