Added a switch to dump minidump modules in minidump_stackwalk.

Added a switch to dump minidump modules in minidump_stackwalk.

In order to figure out what symbols we need associated to a minidump,
it is useful to be able to dump all the modules the minidump contains.

A=dyen@chromium.org
Original Review: https://codereview.chromium.org/1651593002/
BUG=563716
R=dyen@chromium.org

Committed: https://chromium.googlesource.com/breakpad/breakpad/+/cb936a0243c97ae9cd2d4bb19d95dde0421fed6d

[Lei Zhang, 2016-01-29 21:55:12]

thestig@chromium.org changed reviewers:
+ dyen@chromium.org

[David Yen, 2016-01-29 21:56:02]

lgtm

[Lei Zhang, 2016-01-29 21:59:20]

Description was changed from

==========
Added a switch to dump minidump modules in minidump_stackwalk.

In order to figure out what symbols we need associated to a minidump,
it is useful to be able to dump all the modules the minidump contains.

A=dyen@chromium.org
Original Review: https://codereview.chromium.org/1651593002/
BUG=563716
==========

to

==========
Added a switch to dump minidump modules in minidump_stackwalk.

In order to figure out what symbols we need associated to a minidump,
it is useful to be able to dump all the modules the minidump contains.

A=dyen@chromium.org
Original Review: https://codereview.chromium.org/1651593002/
BUG=563716
R=dyen@chromium.org

Committed:
https://chromium.googlesource.com/breakpad/breakpad/+/cb936a0243c97ae9cd2d4bb...
==========

[Lei Zhang, 2016-01-29 21:59:21]

Committed patchset #1 (id:1) manually as
cb936a0243c97ae9cd2d4bb19d95dde0421fed6d (presubmit successful).

[Ted Mielczarek, 2016-02-01 14:23:53]

I wonder if it makes sense to shoehorn this into minidump_stackwalk, or if it
wouldn't make more sense to just make this a standalone binary?

[Lei Zhang, 2016-02-01 18:46:52]

On 2016/02/01 14:23:53, Ted Mielczarek wrote:
> I wonder if it makes sense to shoehorn this into minidump_stackwalk, or if it
> wouldn't make more sense to just make this a standalone binary?

I'm a bit meh about having more binaries, but I'm guess your point is that -b
makes minidump_stackwalk not actually do any stack walking. How about we add -x
to make minidump_stackwalk display the full module path when invoked with any
other switches, let David switch to minidump_stackwalk -m -x, and retire -b?

[David Yen, 2016-02-01 19:20:37]

On 2016/02/01 18:46:52, Lei Zhang wrote:
> On 2016/02/01 14:23:53, Ted Mielczarek wrote:
> > I wonder if it makes sense to shoehorn this into minidump_stackwalk, or if
it
> > wouldn't make more sense to just make this a standalone binary?
> 
> I'm a bit meh about having more binaries, but I'm guess your point is that -b
> makes minidump_stackwalk not actually do any stack walking. How about we add
-x
> to make minidump_stackwalk display the full module path when invoked with any
> other switches, let David switch to minidump_stackwalk -m -x, and retire -b?

Another option is to parse the output from "minidump_dump", would that be
better?

[Ted Mielczarek, 2016-02-01 19:55:34]

Somewhat related, I worked around this problem in our production crash reporting
system by making our stackwalker output JSON:
https://github.com/mozilla/socorro/blob/master/minidump-stackwalk/stackwalker.cc

It's pretty easy to stick any data we want in that output now, and it's exposed
on our webapp for consumption:
https://crash-stats.mozilla.com/report/index/0e922729-ac3d-4c51-8082-8602c216...
(see the raw data tab).

[Lei Zhang, 2016-02-03 02:41:53]

On 2016/02/01 19:20:37, David Yen wrote:
> On 2016/02/01 18:46:52, Lei Zhang wrote:
> > On 2016/02/01 14:23:53, Ted Mielczarek wrote:
> > > I wonder if it makes sense to shoehorn this into minidump_stackwalk, or if
> it
> > > wouldn't make more sense to just make this a standalone binary?
> > 
> > I'm a bit meh about having more binaries, but I'm guess your point is that
-b
> > makes minidump_stackwalk not actually do any stack walking. How about we add
> -x
> > to make minidump_stackwalk display the full module path when invoked with
any
> > other switches, let David switch to minidump_stackwalk -m -x, and retire -b?
> 
> Another option is to parse the output from "minidump_dump", would that be
> better?

If you want to use minidump_dump and revert this CL, that's fine by me too.

[Lei Zhang, 2016-02-03 02:42:20]

On 2016/02/01 19:55:34, Ted Mielczarek wrote:
> Somewhat related, I worked around this problem in our production crash
reporting
> system by making our stackwalker output JSON:
>
https://github.com/mozilla/socorro/blob/master/minidump-stackwalk/stackwalker.cc
> 
> It's pretty easy to stick any data we want in that output now, and it's
exposed
> on our webapp for consumption:
>
https://crash-stats.mozilla.com/report/index/0e922729-ac3d-4c51-8082-8602c216...
> (see the raw data tab).

Neat. Any interest in upstreaming it? Not sure how big of a JSON library we have
to pull in.

[Ted Mielczarek, 2016-02-03 13:58:11]

On 2016/02/03 02:42:20, Lei Zhang wrote:
> Neat. Any interest in upstreaming it? Not sure how big of a JSON library we
have
> to pull in.

It's three actual source files and handful of headers:
https://github.com/mozilla/socorro/blob/master/minidump-stackwalk/Makefile#L21
https://github.com/mozilla/socorro/tree/master/minidump-stackwalk/jsoncpp-src...
https://github.com/mozilla/socorro/tree/master/minidump-stackwalk/jsoncpp-src...

If you think it'd be useful to others I could figure out how to upstream it. The
implementation we're using has some Mozilla-specific bits, but we could likely
factor that out so that it's reusable.

[Lei Zhang, 2016-02-04 23:26:37]

On 2016/02/03 13:58:11, Ted Mielczarek wrote:
> On 2016/02/03 02:42:20, Lei Zhang wrote:
> > Neat. Any interest in upstreaming it? Not sure how big of a JSON library we
> have
> > to pull in.
> 
> It's three actual source files and handful of headers:
> https://github.com/mozilla/socorro/blob/master/minidump-stackwalk/Makefile#L21
>
https://github.com/mozilla/socorro/tree/master/minidump-stackwalk/jsoncpp-src...
>
https://github.com/mozilla/socorro/tree/master/minidump-stackwalk/jsoncpp-src...

Should be fine. We can pull in jsoncpp from
https://chromium.googlesource.com/external/github.com/open-source-parsers/jso...
via DEPS for standalone Breakpad. Chromium already pulls in jsoncpp as well.

> If you think it'd be useful to others I could figure out how to upstream it.
The
> implementation we're using has some Mozilla-specific bits, but we could likely
> factor that out so that it's reusable.

Seems generally useful, and less code for you to maintain in your branch. If you
have the time, please give it a try.