Closed
Bug 1268617
Opened 8 years ago
Closed 8 years ago
Pass -g to rustc
Categories
(Firefox Build System :: General, defect)
Firefox Build System
General
Tracking
(firefox49 fixed)
RESOLVED
FIXED
mozilla49
Tracking | Status | |
---|---|---|
firefox49 | --- | fixed |
People
(Reporter: rillian, Assigned: rillian)
References
Details
Attachments
(1 file)
We don't seem to be passing -g to rustc, which doesn't help with the crash report situation.
Assignee | ||
Updated•8 years ago
|
Product: Toolkit → Core
Assignee | ||
Comment 1•8 years ago
|
||
Enable debug output from the rust compiler when we're doing so for the C/C++ compilers. Review commit: https://reviewboard.mozilla.org/r/49529/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/49529/
Attachment #8746673 -
Flags: review?(ted)
Comment 2•8 years ago
|
||
Comment on attachment 8746673 [details] MozReview Request: Bug 1268617 - Pass -g to rustc on debug builds. r?ted https://reviewboard.mozilla.org/r/49529/#review47055 Adding more stuff to config.mk makes me sad, but this patch is so small and I don't want to make you do busywork to get this fixed. I'll fix it when I move the m4 stuff to moz.configure.
Attachment #8746673 -
Flags: review?(ted) → review+
I had to back this out in https://hg.mozilla.org/integration/mozilla-inbound/rev/3aa433b16d75 because Windows debug devtools tests started failing when this landed: https://treeherder.mozilla.org/logviewer.html#?job_id=27162094&repo=mozilla-inbound
Flags: needinfo?(giles)
Assignee | ||
Comment 5•8 years ago
|
||
Well, that's surprising. Did a try push on top of central for comparison. https://treeherder.mozilla.org/#/jobs?repo=try&revision=9f6622a64da5
Flags: needinfo?(giles)
Comment 6•8 years ago
|
||
So that test hit an assertion, and then the harness was trying to symbolicate the assertion stack, and it failed parsing the Breakpad symbol file because a FUNC line is missing a function name. So there are two bugs here: 1) fix_stack_using_bpsyms.py shouldn't break on FUNC records with missing symbols: https://dxr.mozilla.org/mozilla-central/rev/0a25833062a880f369e6f9f622413a94cc671bf4/tools/rb/fix_stack_using_bpsyms.py#46 2) Either rustc is outputing bad debug info for these functions, or dump_syms is failing to interpret them properly. Looking at the symbol file from that build, I see (among others): ``` FUNC 3eee0 c0 0 3eee0 b 90 284744 3eeeb 1e 91 284744 3ef09 12 59 284722 3ef1b 5 138 284722 3ef20 3d 91 284744 3ef5d f 234 284745 3ef6c 27 139 284722 3ef93 d 234 284745 ``` That function is missing a name! The `284744` there is a file number, which is: FILE 284744 hg:hg.mozilla.org/integration/mozilla-inbound:media/libstagefright/binding/mp4parse/capi.rs:6aa3f079d304 Mashing the info from those two together produces: https://hg.mozilla.org/integration/mozilla-inbound/file/6aa3f079d304/media/libstagefright/binding/mp4parse/capi.rs#l90 so this is mp4parse_new, and at least the line data is right, which is nice!
Comment 7•8 years ago
|
||
Filed bug 1270091 on fix_stack_using_bpsyms.py.
Assignee | ||
Comment 8•8 years ago
|
||
Thanks for the help, Ted. I don't know much about this, but `objdump -g obj/media/libstagefright/liblib.rlib` in my build does show several occurances of `mp4parse_new`, and those are propagated to `liburl.a`. Perhaps the incompatibility is in our symbol extractor then. Contents of the .debug_info section: <3396> DW_AT_linkage_name: (indirect string, offset: 0x13fdf): _ZN3lib4capi12mp4parse_newE <339a> DW_AT_name : (indirect string, offset: 0x13ffb): mp4parse_new Contents of the .debug_pubnames section: Offset Name 3395 mp4parse_new
Comment 10•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/46a1211738cb
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox49:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
Comment 11•8 years ago
|
||
(In reply to Ralph Giles (:rillian) needinfo me from comment #8) > Thanks for the help, Ted. I don't know much about this, but `objdump -g > obj/media/libstagefright/liblib.rlib` in my build does show several > occurances of `mp4parse_new`, and those are propagated to `liburl.a`. > Perhaps the incompatibility is in our symbol extractor then. Yes, but unfortunately the problem you hit in CI was on Windows. :) I'm back from vacation now, I'll file a bug and take a look at it.
Updated•8 years ago
|
Updated•6 years ago
|
Product: Core → Firefox Build System
You need to log in
before you can comment on or make changes to this bug.
Description
•