minidump_stackwalk: implement -a <address> option

minidump_stackwalk: implement -a <address> option

Implement an option to symbolize additional addresses during minidump
symbolization. Primarily this is useful when symbolizing a Chromium minidump
that contains an additional backtrace added by the CrZombie class.

[jaysoffian]

I hope this isn't too ugly. There's now there places that fill in the StackFrame
object (FillStackFrame() which I just added, Stackwalker::Walk(), and
Stackwalker::InstructionAddressSeemsValid(). Minimally FillStackFrame() and
InstructionAddressSeemsValid() could probably be combined.

But I thought I'd through this out there as a first pass.

[Mark Mentovai]

I don’t quite get it. How’s this all intended to work?

[jaysoffian]

On 2012/09/28 21:17:47, Mark Mentovai wrote:
> I don’t quite get it. How’s this all intended to work?

We have a Python script which uses minidump_stackwalk to symbolize
Breakpad-uploaded minidumps.

The Python script has the metadata uploaded by Breakpad along with the minidump.
When it sees that the crash metadata contains zombie_dealloc_bt (added by
objc_zombie.mm), it'll feed those addresses to minidump_stackwalk via the -a
option added by this patch.

That way all the symbolization can be done at once.

[Mark Mentovai]

OK, I was trying to figure out if you were using objc_zombie the same way we
are: the zombie_dealloc_bt attribute is out-of-band relative to the minidump
file itself.

minidump_stackwalk is intended to operate on minidumps and perform stackwalks on
them. Merely translating a series of addresses delivered out-of-band from the
minidump (not accessing any data in the minidump) and not using that information
to perform a new stackwalk or inform the existing stackwalk (zombie_dealloc_bt
is “already walked”) is outside of the scope of minidump_stackwalk.

[jaysoffian]

On 2012/09/28 21:30:56, Mark Mentovai wrote:
> OK, I was trying to figure out if you were using objc_zombie the same way we
> are: the zombie_dealloc_bt attribute is out-of-band relative to the minidump
> file itself.
> 
> minidump_stackwalk is intended to operate on minidumps and perform stackwalks
on
> them. Merely translating a series of addresses delivered out-of-band from the
> minidump (not accessing any data in the minidump) and not using that
information
> to perform a new stackwalk or inform the existing stackwalk (zombie_dealloc_bt
> is “already walked”) is outside of the scope of minidump_stackwalk.

Don't you need the minidump in order to know the offsets of all the loaded
modules and their debug IDs? Without that information how can you symbolize an
arbitrary address?

[Mark Mentovai]

I’m not saying that there isn’t room for a tool that does this, I’m saying that
I don’t think that it’s a good addition to minidump_stackwalk.

Robert Sesek’s written the tool that we use to do this, and he should have time
to open-source it shortly (per the other e-mail thread).

[jaysoffian]

On 2012/09/28 21:51:47, Mark Mentovai wrote:
> I’m not saying that there isn’t room for a tool that does this, I’m saying
that
> I don’t think that it’s a good addition to minidump_stackwalk.

It seems sub-optimal to crack open the minidump multiple times if you know
you've got additional addresses to translate at the time of stack
walking/symbolizing the minidump itself.

> Robert Sesek’s written the tool that we use to do this, and he should have
time
> to open-source it shortly (per the other e-mail thread).

Okay. I'm also happy to refactor this change out into an minidump_atos or some
such.