OSX: Process keeps running after the minidump is written, and triggers the mac crashreporter

[GoogleCodeExporter]

I'm not quite sure how to reproduce this reliably yet...

When memory is corrupted, I can get into a situation where breakpad writes
the minidump and then the process continues execution. I've caught it in
GDB, and the stacks look like this:

Main/crashing thread:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000004
#0 0x1e4c84cc in nsComponentManagerImpl::GetServiceByContractID
#1 0x1f1b0f80 in CallGetService ()
etc

Breakpad handler thread:

#0 ... in mach_msg_trap ()
#1 ... in mach_msg ()
#2 ... in exception_raise (0
#3 ... in ForwardException
#4 ... in _Xexception_raise ()
#5 ... in exc_server ()
#6 ... in google_breakpad::ExceptionHandler::WaitForMessage at
exception_handler.cc:410
#7 ... in _pthread_body ()

When I run minidump_stackwalk on the minidump file, I see the following output:

Operating system: Mac OS X
                  10.4.9 3P2137

CPU: x86
     family 0 model 0 stepping 0

No crash

Thread 0
 0 0x1e4c84cc
   ...
 1 0x1f1b0f7f
   ...
 etc

I find the "no crash" notation especially suspicious.

Original issue reported on code.google.com by bsmedb...@gmail.com on 9 May 2007 at 4:15

[GoogleCodeExporter]

Original comment by mmento...@gmail.com on 9 May 2007 at 6:12

• Added labels: Component-Client-Handler, OpSys-OSX

[GoogleCodeExporter]

I've traced this back to malloc heap corruption of DynamicImage() members. The
attached log was done with debug-by-printf... you can see malloc errors while 
walking
the dynamic images like so:
firefox-bin(3114,0x1f801c00) malloc: *** error for object 0x38523be0: incorrect
checksum for freed object - object was probably modified after being freed, 
break at
szone_error to debug

I'm quite surprised that the handler is doing any allocations at all... the 
Windows
handler was paraniod about doing no allocations and using preallocated buffers.

I think we should probably be using a preallocated buffer and arenas for 
objects that
need to be created during handling. But I'm wondering... why do we need this
complicated object structure? Couldn't most of that work be done directly in 
loops
and written to the dumpfile without keeping a DynamicImages() object around at 
all?

Original comment by bsmedb...@gmail.com on 17 May 2007 at 6:26

Attachments:

• crash.output

[GoogleCodeExporter]

I replaced the dyld calls with the DynamicImage stuff in order to inspect the 
crashed process and generate a 
report from another process.  So in our usage, the mallocs are not an issue 
since they're not happening in the 
crashed process itself.
Probably, what we should do for the case where the minidump generation happens 
in the crashed process is 
revert back to the old dyld calls.

Original comment by ladderbr...@gmail.com on 17 May 2007 at 6:50

[GoogleCodeExporter]

I've attached a patch to minidump_generator.cc to avoid these mallocs if the 
generation is happening in the 
crashed process

Original comment by ladderbr...@gmail.com on 21 May 2007 at 9:13

Attachments:

• issue167.patch

[GoogleCodeExporter]

Original comment by ladderbr...@gmail.com on 22 May 2007 at 5:43

• Changed state: Fixed