increase exception handler stack size for dumping thread

When running unittests under ASAN, we see that these code paths can
slightly smash the stack.  Double it to avoid that.

[ RUN      ] ExceptionHandlerTest.InstructionPointerMemoryMinBound
=================================================================
==12775== ERROR: AddressSanitizer: stack-buffer-overflow on address 0xf6787614 at pc 0xf7516b29 bp 0xf6786d38 sp 0xf6786d30
READ of size 4 at 0xf6787614 thread T0
    #0 0xf7516b28 (/build/x86-generic/tmp/portage/chromeos-base/google-breakpad-1181-r66/work/google-breakpad-1181/build/src/client/linux/linux_client_unittest_shlib+0x69eb28)
Shadow byte and word:
  0x3ecf0ec2: f2
  0x3ecf0ec0: f2 f2 f2 f2
More shadow bytes:
  0x3ecf0eb0: f2 f2 f2 f2
  0x3ecf0eb4: 04 f4 f4 f4
  0x3ecf0eb8: f2 f2 f2 f2
  0x3ecf0ebc: 04 f4 f4 f4
=>0x3ecf0ec0: f2 f2 f2 f2
  0x3ecf0ec4: 04 f4 f4 f4
  0x3ecf0ec8: f2 f2 f2 f2
  0x3ecf0ecc: 04 f4 f4 f4
  0x3ecf0ed0: f2 f2 f2 f2
Stats: 0M malloced (0M for red zones) by 2757 calls
Stats: 0M realloced by 0 calls
Stats: 0M freed by 2229 calls
Stats: 0M really freed by 0 calls
Stats: 3M (899 full pages) mmaped in 7 calls
  mmaps   by size class: 7:4095; 8:2047; 9:1023; 10:511; 14:32; 16:16;
  mallocs by size class: 7:1831; 8:590; 9:85; 10:233; 14:3; 16:15;
  frees   by size class: 7:1459; 8:437; 9:84; 10:232; 14:2; 16:15;
  rfrees  by size class:
Stats: malloc large: 15 small slow: 25
==12775== ABORTING

BUG=chromium:293519
TEST=ran unittests under ASAN and they now pass
R=benchan@chromium.org

Review URL: https://breakpad.appspot.com/636002

git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1224 4c0a9323-5329-0410-9bdc-e9ce6186880e
This commit is contained in:
vapier@chromium.org 2013-10-23 05:12:37 +00:00
parent 6f3426a156
commit 8586f6e288

View file

@ -434,7 +434,9 @@ bool ExceptionHandler::GenerateDump(CrashContext *context) {
if (IsOutOfProcess())
return crash_generation_client_->RequestDump(context, sizeof(*context));
static const unsigned kChildStackSize = 8000;
// Allocating too much stack isn't a problem, and better to err on the side
// of caution than smash it into random locations.
static const unsigned kChildStackSize = 16000;
PageAllocator allocator;
uint8_t* stack = (uint8_t*) allocator.Alloc(kChildStackSize);
if (!stack)