Closed
Bug 1510698
Opened 6 years ago
Closed 6 years ago
Missing symbols for libxul in recent builds
Categories
(Firefox Build System :: General, defect)
Firefox Build System
General
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: jkratzer, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [fuzzblocker])
At some point between build 20181127215721 and 20181128095655 it appears that symbols for libxul are no longer packaged with debug builds on linux. Windows builds appear to be fine.
Relevant output from minidump_stackwalk:
2018-11-28 17:24:31: http_symbol_supplier.cc:553: INFO: HTTPSymbolSupplier: querying http://s3-us-west-2.amazonaws.com/org.mozilla.crash-stats.symbols-public/v1/firefox-bin/8E77AE31EB177A206FE897CD2CE80DE00/firefox-bin.sym
2018-11-28 17:24:31: http_symbol_supplier.cc:467: INFO: HTTPSymbolSupplier: HTTP response code: 404
2018-11-28 17:24:31: stackwalker.cc:97: INFO: Couldn't load symbols for: /home/ubuntu/firefox/firefox-bin|8E77AE31EB177A206FE897CD2CE80DE00
2018-11-28 17:24:31: simple_symbol_supplier.cc:196: INFO: No symbol file at /tmp/libxul.so/F02840F0EB4E0C96C7C562D8008EFE590/libxul.so.sym
2018-11-28 17:24:31: http_symbol_supplier.cc:553: INFO: HTTPSymbolSupplier: querying http://s3-us-west-2.amazonaws.com/org.mozilla.crash-stats.symbols-public/v1/libxul.so/F02840F0EB4E0C96C7C562D8008EFE590/libxul.so.sym
2018-11-28 17:24:31: http_symbol_supplier.cc:467: INFO: HTTPSymbolSupplier: HTTP response code: 404
2018-11-28 17:24:31: stackwalker.cc:97: INFO: Couldn't load symbols for: /home/ubuntu/firefox/libxul.so|F02840F0EB4E0C96C7C562D8008EFE590
2018-11-28 17:24:31: basic_code_modules.cc:110: INFO: No module at 0x0
2018-11-28 17:24:31: basic_code_modules.cc:110: INFO: No module at 0x7fffb8a0d090
2018-11-28 17:24:31: basic_code_modules.cc:110: INFO: No module at 0x0
Reporter | ||
Updated•6 years ago
|
Whiteboard: [fuzzblocker]
Comment 2•6 years ago
|
||
Just some informational bits, it looks like these are the two nightlies you're talking about:
https://hg.mozilla.org/mozilla-central/rev/204cda7581188cfc8c8ef11dce4680dadf2b43bb
https://hg.mozilla.org/mozilla-central/rev/5c66354bff282452a6f1a3c911fa8756b6e752af
So the regression range would be:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=204cda7581188cfc8c8ef11dce4680dadf2b43bb&tochange=5c66354bff282452a6f1a3c911fa8756b6e752af
Nothing immediately jumps out. I'll dig in a little more.
Comment 3•6 years ago
|
||
This seems to be limited to debug builds. I realized that we get the num_static_constructors metric from the dump_syms output so I looked at the graphs for that metric and it was obvious where this broke:
https://treeherder.mozilla.org/perf.html#/graphs?series=autoland,1468482,1,2&highlightedRevisions=bba74d02a136
This points to bug 1501796 breaking things. Presumably nasm must be emitting some debug info that dump_syms can't deal with.
Blocks: 1501796
Flags: needinfo?(ted)
Comment 4•6 years ago
|
||
We could try explicitly specifying a different debug format for nasm (or no debug info at all). https://www.nasm.us/doc/nasmdoc2.html#section-2.1.12
Is there a way to reproduce this on try?
Comment 6•6 years ago
|
||
(In reply to Thomas Daede [:TD-Linux] from comment #4)
> Is there a way to reproduce this on try?
It seems to reproduce on all Linux debug builds, the logs just don't show anything informative.
Comment 7•6 years ago
|
||
Everything seemed to back to normal late last week until this morning. Any idea what changed?
I will disable fuzzing on debug builds again for now.
Flags: needinfo?(tdaede)
Comment 8•6 years ago
|
||
Yes, instead of building the whole binary with nasm, we switched back to yasm. Then we turned on dav1d assembly, which builds only the dav1d .o files with nasm. I guess putting *any* object files generated with nasm breaks symbols.
Flags: needinfo?(tdaede)
Comment 9•6 years ago
|
||
I'll see if I can repro this locally and eventually fix dump_syms to accommodate for whatever DWARF debuginfo nasm is spitting out.
Comment 10•6 years ago
|
||
I reproduced this with my local build. dump_syms is failing with an abort() while parsing the DWARF data here:
I'll try and figure out what's going on.
Comment 11•6 years ago
|
||
The DWARF abbreviations generated by nasm 2.13.01 are not terminated causing the DWARF parser to fail:
https://bugzilla.nasm.us/show_bug.cgi?id=3392417
This was already fixed in nasm 2.13.02 so we'll need to bump the version we use.
Comment 12•6 years ago
|
||
Gabriele any updates? Do you know when bug 1520163 might be resolved?
Flags: needinfo?(gsvelto)
Comment 13•6 years ago
|
||
I don't know unfortunately, if there's no other way we might roll out a workaround in the meantime.
Flags: needinfo?(gsvelto)
Comment 14•6 years ago
|
||
Is this still a problem? Bug 1520163 should have fixed it.
Flags: needinfo?(jkratzer)
Comment 16•6 years ago
|
||
Good, closing as fixed.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•