no lib.xul symbols for crash stack

NEW
Unassigned

Status

Testing
BrowserTest
3 years ago
3 years ago

People

(Reporter: krizsa, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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
Created attachment 8614842 [details]
bug1171109.stack

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.
You need to log in before you can comment on or make changes to this bug.