631645 - OS X symbol dumper emits relative paths for some filenames

Status: RESOLVED FIXED

(Toolkit :: Crash Reporting, defect)

Description

[Jeff Muizelaar [:jrmuizel]]

This crash https://crash-stats.mozilla.com/report/index/b2002b04-163e-47f7-b75b-4c5232110204 is missing line information for the call to mozilla::layers::LayerManagerOGL::Initialize.

It also has bad paths for LayerManagerOGL.h and pldhash.c.

Comment 1

[(not currently active) Ted Mielczarek]

The bad paths bit is known, any source that gets built from the objdir doesn't get handled properly because it's not under the srcdir so we can't link it back to the source.

The missing source file bit is interesting, the line in the raw dump looks like:
0|5|XUL|mozilla::layers::LayerManagerOGL::Initialize|hg:hg.mozilla.org/mozilla-central::1c2d53a2dcfb|1817|0xe

so somehow we lost the filename when we were mangling it? That's also claiming it's on line 1817, and LayerManagerOGL.cpp doesn't have that many lines, so it might be something that got inlined. I'll have to look more closely at the symbol file.

Comment 2

[(not currently active) Ted Mielczarek]

Ok, so the missing source file is:
FILE 524 ../../dist/include/GLContext.h

I guess we shouldn't mangle that path into an empty file, so that's a bug, but I also don't know why dump_syms spits out these relative paths. Even if we could do something smarter, what's that path relative to? Is that really what's in the debug info? If so, how are tools supposed to resolve that filename?

Comment 3

[(not currently active) Ted Mielczarek]

Attachment: dwarfdump of the line in question

Here's the output of:
dwarfdump --arch=x86_64 --lookup=0xeb7207 ./XUL.dSYM

which is the line referenced in the crash report. It looks like the DWARF dumping code attempts to resolve relative paths, but it's not doing so in this case.

Comment 4

[(not currently active) Ted Mielczarek]

Actually it looks like we might just intentionally spit out the relative paths here:
http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/google-breakpad/src/common/dwarf_line_to_module.cc#85

That doesn't seem great.

Comment 5

[Jim Blandy :jimb]

(In reply to comment #4)
> Actually it looks like we might just intentionally spit out the relative paths
> here:
> http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/google-breakpad/src/common/dwarf_line_to_module.cc#85
> 
> That doesn't seem great.

It looks like we should be checking the DW_AT_comp_dir attribute of the compilation unit, and passing that into the line number parser. This would be:

- a new field of DwarfCUToModule::CUContext to hold the DW_AT_comp_dir value;

- a new argument to LineToModuleFunctor::operator(), to which DwarfCUToModule::Finish should pass along the DW_AT_comp_dir value;

- a new argument to the DwarfLineToModule constructor (or perhaps a DefineCompilationDir member function), to which lineToModuleFunctor::operator() should pass the directory; it should probably just store the directory as entry zero in directories_;

- and a change to DwarfLineToModule to not treat directory zero specially.

I may not have time to get to this for a while.

Comment 6

[(not currently active) Ted Mielczarek]

Ok, that's fine, thanks for commenting, since you know that code so much better than I do! I'm going to split this bug in two, and file a separate bug on making symbolstore.py not eat these relative paths, so that we can at least get the filenames in the dump output.

Comment 7

[(not currently active) Ted Mielczarek]

Filed bug 632616 on symbolstore.py.

Comment 8

[Jim Blandy :jimb]

(In reply to comment #6)
> Ok, that's fine, thanks for commenting, since you know that code so much better
> than I do!

That code is... not the clearest in the world.

Comment 9

[(not currently active) Ted Mielczarek]

There's a patch upstream for this: 
http://breakpad.appspot.com/385001/

Comment 10

[(not currently active) Ted Mielczarek]

That patch landed as upstream r1106, which we picked up in bug 839126.