aboutsummaryrefslogtreecommitdiff
path: root/m4/ltversion.m4
diff options
context:
space:
mode:
authorPrimiano Tucci <primiano@google.com>2015-09-22 09:11:24 +0100
committerPrimiano Tucci <primiano@google.com>2015-09-22 09:11:24 +0100
commit4d06db5a1f5d3fb2f25dbc40577ca4e2149911b0 (patch)
tree92786ec30e1ca0d08b9741d88f6dd51beb02e538 /m4/ltversion.m4
parentFixup a bad strcmp call landed in previous commit (diff)
downloadbreakpad-4d06db5a1f5d3fb2f25dbc40577ca4e2149911b0.tar.xz
Linux ExceptionHandler: don't allocate the CrashContext on the stack
On Android the size of the alternate stack can be very small (8k). Even if breakpad uses sigaltstack to increase the size of the alternate stack during initialization, that call affects only the main thread. On Android, the libc's pthread initializer reset the sigaltstack to 8k. When entering a signal handler, the kernel typically pushes the context on the alternate stack. On arm64, sizeof(CrashContext) is ~5k, which leaves 3k of usable stack for breakpad. On top of that, breakpad allocates another struct CrashContext on the stack. In the case of Android arm64, then, breakpad ends up using 5k + 5k > 8k of stack, which causes a stack overflow. This got unnoticed in Android L, as the alternate stack didn't have red-zones between them, so breakpad was often happily overflowing onto the next thread's stack. This is not the case anymore [1]. This CL moves the CrashContext into a global variable. It should be safe as the ExceptionHandlers are serialized on a mutex. [1] https://android.googlesource.com/platform/bionic/+/595752f623ae88f7e4193a6e531a0805f1c6c4dc BUG=374 R=mark@chromium.org Review URL: https://codereview.chromium.org/1354923002 .
Diffstat (limited to 'm4/ltversion.m4')
0 files changed, 0 insertions, 0 deletions