Closed Bug 631645 Opened 9 years ago Closed 6 years ago

OS X symbol dumper emits relative paths for some filenames

Categories

(Toolkit :: Crash Reporting, defect)

x86
macOS
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla21

People

(Reporter: jrmuizel, Assigned: ted)

References

Details

Attachments

(1 file)

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.
Blocks: 612095
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.
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?
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.
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.
(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.
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.
Summary: Missing line number information on OS X crashes → OS X symbol dumper emits relative paths for some filenames
Filed bug 632616 on symbolstore.py.
(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.
There's a patch upstream for this: 
http://breakpad.appspot.com/385001/
That patch landed as upstream r1106, which we picked up in bug 839126.
Status: NEW → RESOLVED
Closed: 6 years ago
Depends on: 839126
Resolution: --- → FIXED
Assignee: nobody → ted
Target Milestone: --- → mozilla21
You need to log in before you can comment on or make changes to this bug.