Closed Bug 1076848 Opened 5 years ago Closed 5 years ago

Source Server indexing not working with header files from dist/include

Categories

(Toolkit :: Crash Reporting, defect)

All
Windows 7
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla41
Tracking Status
firefox41 --- fixed

People

(Reporter: ted, Assigned: ted)

References

Details

Attachments

(1 file, 1 obsolete file)

(In reply to :dmajor (away 3-7 October) from bug 462159 comment #18)
> Looking at the first October nightly:
> http://symbols.mozilla.org/firefox/xul.pdb/28D210BA209049E2B10F488F7C4963812/
> xul.sym
> 
> nsTArray is my usual example since it's so common:
> FILE 477 hg:hg.mozilla.org/mozilla-central:xpcom/glue/nsTArray.h:14665b1de5ee
> 
> I can pull it up manually in a browser:
> http://hg.mozilla.org/mozilla-central/raw-file/14665b1de5ee/xpcom/glue/
> nsTArray.h
> 
> But the debugger can't. With |!sym noisy| I get this warning:
> SRCSRV: 
> c:\builds\moz2_slave\m-cen-w32-ntly-000000000000000\build\obj-
> firefox\dist\include\nstarray.h not indexed

I poked at this more, and I figured it out. I downloaded http://symbols.mozilla.org/firefox/firefox.pdb/C75EDDEAFB874537A034DB1A380D33062/firefox.pd_, decompressed it, and then pulled out the source indexing stream using:
/c/Program\ Files/Debugging\ Tools\ for\ Windows\ \(x64\)/srcsrv/pdbstr.exe -r -p:firefox.pdb -s:srcsrv

grepping that output for nsTArray shows (among other lines):
c:/builds/moz2_slave/m-cen-w32-ntly-000000000000000/build/xpcom/glue/nsTArray.h*xpcom/glue/nsTArray.h*6a63bcb6e0d3

So the debugger is trying to match the full original path that the file was included from (in dist/include), but we're doing the path translation a little too early here and sticking the srcdir path in the source stream so it can't find the file it's looking for.

This actually doesn't look too hard to fix, the path we stick into the source index is saved here:
http://hg.mozilla.org/mozilla-central/annotate/2399d1ae89e9/toolkit/crashreporter/tools/symbolstore.py#l652

and we don't use that variable anywhere else, we could probably just move its assignment up three lines to before we do any massaging on it and it ought to work:
http://hg.mozilla.org/mozilla-central/annotate/2399d1ae89e9/toolkit/crashreporter/tools/symbolstore.py#l642

I assume using the filename as it comes straight from the PDB here would make the debugger happy, since that's where the debugger is getting the filename anyway...
I have a patch (the simple thing I mentioned above). Building locally and running "./mach buildsymbols" then copying + expanding the firefox.pd_ file out of dist/crashreporter-symbols and running pdbstr on it like so shows:
/c/Program\ Files\ \(x86\)/Windows\ Kits/8.1/Debuggers/x86/srcsrv/pdbstr.exe -r -p:firefox.pdb -s:srcsrv | grep nsTArray
c:\build\debug-mozilla-central\dist\include\nsTArray.h*xpcom/glue/nsTArray.h*ae85789070ff

So this should work.
Attached file MozReview Request: bz://1076848/ted (obsolete) —
/r/8335 - bug 1076848 - fix source server indexing for headers from dist/include. r?dmajor

Pull down this commit:

hg pull -r ae85789070ff53b106a0ac322cb2741d406d7a8f https://reviewboard-hg.mozilla.org/gecko/
Attachment #8602737 - Flags: review?(dmajor)
Comment on attachment 8602737 [details]
MozReview Request: bz://1076848/ted

https://reviewboard.mozilla.org/r/8333/#review7039

Ship It!
Attachment #8602737 - Flags: review?(dmajor) → review+
Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/b0ea7f4820e0 because it turned out not to be a great thing to have a 3 hour hang in make check.
I believe the hang was from the change in bug 528092, I'm sorry about that. I'll run these by the try server before landing again.
https://hg.mozilla.org/mozilla-central/rev/c166802eb89a
Assignee: nobody → ted
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
Attachment #8602737 - Attachment is obsolete: true
Attachment #8618386 - Flags: review+
You need to log in before you can comment on or make changes to this bug.