Open
Bug 1171109
Opened 9 years ago
Updated 2 years ago
no lib.xul symbols for crash stack
Categories
(Testing :: Mochitest, defect)
Testing
Mochitest
Tracking
(Not tracked)
NEW
People
(Reporter: gkrizsanits, Unassigned)
Details
Attachments
(1 file)
(deleted),
text/plain
|
Details |
For some reason the stack is not human readable, seems like applying the libxul symbols failed.
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/gkrizsanits@mozilla.com-bfeffadd90b5/try-linux/try_ubuntu32_vm_test-mochitest-e10s-browser-chrome-1-bm06-tests1-linux32-build676.txt.gz
Comment 1•9 years ago
|
||
So you were right, being an OOM crash made Breakpad fail to write some useful information in this case. Specifically, it tries to mmap libraries in to get their Build IDs and fails, so it put all zeroes in libxul's debug ID field. The test log doesn't actually have enough information for you to determine this yourself, sadly.
Running it locally showed:
2015-06-03 15:38:44: simple_symbol_supplier.cc:196: INFO: No symbol file at ./symbols//libxul.so/000000000000000000000000000000000/libxul.so.sym
2015-06-03 15:38:44: stackwalker.cc:97: INFO: Couldn't load symbols for: libxul.so|000000000000000000000000000000000
To get a useful stack I made a symlink to the actual symbols:
ln -s /tmp/symbols/libxul.so/9033B2625D1AA8385B01A6FF5872A4C90/ /tmp/symbols/libxul.so/000000000000000000000000000000000
We could probably fix Breakpad to not mmap the entire file into memory, libxul is pretty big and all it really needs is to read the build ID out of the ELF headers.
Assignee | ||
Updated•7 years ago
|
Component: BrowserTest → Mochitest
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•