Open Bug 1171109 Opened 4 years ago Updated 2 years ago
.xul symbols for crash stack
For some reason the stack is not human readable, seems like applying the libxul symbols failed. http://firstname.lastname@example.org/try-linux/try_ubuntu32_vm_test-mochitest-e10s-browser-chrome-1-bm06-tests1-linux32-build676.txt.gz
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.
Component: BrowserTest → Mochitest
You need to log in before you can comment on or make changes to this bug.