OSX: Process keeps running after the minidump is written, and triggers the mac crashreporter about google-breakpad HOT 5 CLOSED

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?

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.

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