mac dump file questions

[notrege]

Apologies for cross posting, but I haven't gotten any replies in
google-breakpad-discuss and I'd really appreciate some help with this.

I'm just getting started with Breakpad and have a few questions about
it's
use with a Mac.

First, I didn't get valid line numbers from minidump_stackwalk until I
changed the Debug information format from DWARF to stabs. Is DWARF
supported?

Second, for a crashed application I get the current code line for each
thread, but not the stack of call frames. I do get all of the call
frames for Windows and it would be very useful to get this for the Mac
as well.

Last, for an on demand minidump (google_breakpad::MinidumpGenerator
md.Write("/tmp/test.dmp")) I don't get any line numbers or call frame
stacks so it isn't very useful. Again, I get both line numbers and
all call frames for Windows.

Chances are these are all 3 related and I'd really appreciate insight
into getting complete stacks or confirmation that this is simply a
known limitation.

thanks for any help!
jim

[Jim Blandy]

On Wed, Oct 27, 2010 at 7:03 PM, notrege <jmef...@comcast.net> wrote:
> First, I didn't get valid line numbers from minidump_stackwalk until I
> changed the Debug information format from DWARF to stabs.   Is DWARF
> supported?

Yes, DWARF is supported on the Mac. Are you using the current SVN HEAD sources?

> Second, for a crashed application I get the current code line for each
> thread, but not the stack of call frames.   I do get all of the call
> frames for Windows and it would be very useful to get this for the Mac
> as well.

You should be able to get a backtrace. Which architecture is your
program? If it is x86 or x86_64, then those are both known to work.

[Ted Mielczarek]

On Wed, Oct 27, 2010 at 10:03 PM, notrege <jmef...@comcast.net> wrote:
> Apologies for cross posting, but I haven't gotten any replies in
> google-breakpad-discuss and I'd really appreciate some help with this.
>
> I'm just getting started with Breakpad and have a few questions about
> it's
> use with a Mac.
>
> First, I didn't get valid line numbers from minidump_stackwalk until I
> changed the Debug information format from DWARF to stabs.   Is DWARF
> supported?

DWARF is supported, but you need to run dump_syms on the .dSYM bundle.
If you're building using XCode, it should automatically run dsymutil
for you and produce a .dSYM bundle next to your binary. If you're
building using some other setup, you'll have to run "dsymutil
/path/to/binary" to produce it.

-Ted

[notrege]

Thanks Jim and Ted.

> Yes, DWARF is supported on the Mac.  Are you using the current SVN HEAD sources?

Fairly recent - I think I last updated about two weeks ago.

> You should be able to get a backtrace.  Which architecture is your
> program?  If it is x86 or x86_64, then those are both known to work.

It's fat binary for x86 and ppc. It definitely works to some degree
- using stabs I get the correct line for a segV, but not all of the
call frames.

I see 3 linker options in Xcode (stabs, DWARF, and DWARF with dSYM
file. As I said, limited success with stabs, none with DWARF.
From Ted's reply it sounds like I should try DWARF with dSYM file -
will let you know how that goes.

appreciate the help,
jim

[notrege]

Progress!!! After changing to DWARF with dSYM I'm getting backtraces
for a segv - very, very cool.

One thing doesn't seem to be working quite right - if I generate an
"on demand" dump using:

google_breakpad::MinidumpGenerator md;
return md.Write(path.c_str());

I get a dump, but the output from minidump_stackwalk doesn't look
correct at all. I can see my thread waiting on an exception:

1 test!google_breakpad::ExceptionHandler::WaitForMessage
[exception_handler.cc : 509 + 0x29]

but I don't see a thread that looks anything like the one calling
md.Write. The objective is to have the equivalent of an assert that
will write a minidump before terminating so the backtrace for the
thread calling md.Write is the one I'd like to see.

thanks for the help,
jim

[Ted Mielczarek]

I believe by default minidump_stackwalk omits the thread that wrote
the minidump. You probably want to call
ExceptionHandler::WriteMinidump, which will signal the background
thread to do the actual dump generation, and that thread will be the
one omitted from the dump instead.

-Ted

[notrege]

> I believe by default minidump_stackwalk omits the thread that wrote
> the minidump. You probably want to call
> ExceptionHandler::WriteMinidump, which will signal the background
> thread to do the actual dump generation, and that thread will be the
> one omitted from the dump instead.
>
> -Ted

Thanks Ted. You're absolutely right, but I'm using the Framework API
and I don't think this exposes ExceptionHandler::WriteMinidump.
Assuming that is the case, a very simple alternative is just to call
either MinidumpGenerato.Write or the Framework
BreakpadGenerateAndSendReport from a new thread. Seems to work.

thanks for pointing me in the right direction,
jim