807007 - Somehow differentiate between OOM crashes and "real" crashes in B2G

Status: RESOLVED WORKSFORME

(Firefox OS Graveyard :: General, defect)

Description

[Justin Lebar (not reading bugmail)]

Right now QA can't tell whether a crash is due to OOM or an "actual" crash.  It would be helpful to differentiate between these (e.g. for bug 806641).

Margaret, does your crash reporter give us any insight here?  What does the crash stack look like when we're killed by the kernel for OOM?  (To be clear, the kernel killing us is not the only way we might crash on OOM; infallible malloc can do us in, too.  I don't know which crash mechanism will be more common.)

Comment 1

[Dave Hylands [:dhylands]]

To the best of my knowledge, there is no crash stack when a process is killed due to OOM. It just disappears.

The parent process gets notified that the child died, but the child doesn't get a chance to even observe the crash.

Bug 805476 would allow you to see a logcat when this happens, but right now, the *only* way that I'm aware of determining if a child died due to OOM is to look in dmesg.

Comment 2

[:Margaret Leibovic]

The crash reporter work I've been doing just adds a UI layer to the existing crash reporter logic, so I haven't been digging into the way we create stacks. The crash data for child process crashes is sent with the"ipc:content-shutdown" notification:
http://mxr.mozilla.org/mozilla-central/source/dom/ipc/ContentParent.cpp#653

If we don't get that notification for OOM, then we won't be reporting a crash.

Comment 3

[Justin Lebar (not reading bugmail)]

Maybe bug 805476 plus outputting the crash stack to logcat (if we don't already do that) would be sufficient for QA's purposes.

Comment 4

[Dave Hylands [:dhylands]]

There is no crash stack to output because the child gets killed using SIGKILL

Comment 5

[Justin Lebar (not reading bugmail)]

(In reply to Dave Hylands [:dhylands] from comment #4)
> There is no crash stack to output because the child gets killed using SIGKILL

Correct, in the case of the kernel killing us.  I'm saying that we should output the crash stack when we get one, because infallible malloc might have done us in, and that's also an "OOM crash" from QA's perspective.

Comment 6

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

The lowmemkiller driver is going to be the 99.9% common case for memory-pressure process exits.  It would be very accurate to assume crash report => non-memory-pressure crash.

Comment 7

[(not currently active) Ted Mielczarek]

If we do crash due to infallible malloc hitting OOM we have an annotation in crash reports now. We annotate with "OOMAllocationSize" and the size we were attempting to malloc. I'm not sure that it gets exposed in the Socorro UI though.

Comment 8

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

I don't think there's anything left for us to do here.