1171109 - no lib.xul symbols for crash stack

Status: NEW

(Testing :: Mochitest, defect)

Description

[Gabor Krizsanits (INACTIVE)]

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/[e-mail]-bfeffadd90b5/try-linux/try_ubuntu32_vm_test-mochitest-e10s-browser-chrome-1-bm06-tests1-linux32-build676.txt.gz

Comment 1

[(not currently active) Ted Mielczarek]

Attachment: 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.