857108 - Empty crash dumps on some devices

Status: RESOLVED INVALID

(Toolkit :: Crash Reporting, defect)

Description

[Mike Hommey [:glandium]]

On some devices, /proc/self/auxv is unreadable on non-debuggable, and breakpad can't handle this situation. See bug 693284 for a similar problem with the custom linker, which was fixed in the new linker code.
https://github.com/glandium/faulty.lib/blob/master/linker/ElfLoader.cpp#L440

I wonder if ignoring the failure to read auxv would be enough for a short term fix (it's only used to find the linux gate and the executable entry point).

Comment 1

[Mike Hommey [:glandium]]

https://breakpad.appspot.com/550002/
https://breakpad.appspot.com/560002/
https://breakpad.appspot.com/562002/
https://breakpad.appspot.com/571003/
https://breakpad.appspot.com/573002/
https://breakpad.appspot.com/572003/

Comment 2

[Mike Hommey [:glandium]]

And this still doesn't work because reading /proc/pid/maps throws EACCESS :(

Comment 3

[Mike Hommey [:glandium]]

In the end, this bug doesn't exist. The reason is this:
http://hg.mozilla.org/mozilla-central/file/7f68735fc8da/toolkit/crashreporter/google-breakpad/src/client/linux/handler/exception_handler.cc#l391

PR_SET_DUMPABLE overcomes the fact that /proc/self/auxv is unreadable (and other things, too, it turns out /proc/self/maps is unreadable too, and ptrace can't attach), but it only does so if the signal was received directly, or with a kill call _from the process itself_ ; i was trying to kill -11 the process from a shell, which doesn't trigger that code.

This is also why debuggerd is unable to throw stack traces in logcat for crashes happening before libxul is loaded.