734703 - Use a less generic signature for OOM crashes with missing stacks

Status: RESOLVED WONTFIX

(Socorro :: General, task)

Description

[Jesse Ruderman]

Split from bug 725024:

I think we should modify the signature generation algorithm so that when OOMAllocationSize is set but no other information is available, the signature is "mozalloc_abort" instead of "empty signature".  This would match the cases where we do have a stack trace, such as bp-f9122be1-204d-4c5a-b49e-f0b5e2120304.

KaiRo would prefer "EMPTY: OOM while allocating", grouping with the busted-stack reports rather than with the OOMs reports.  Maybe he can explain why :)

Comment 1

[Robert Kaiser]

(In reply to Jesse Ruderman from comment #0)
> KaiRo would prefer "EMPTY: OOM while allocating", grouping with the
> busted-stack reports rather than with the OOMs reports.  Maybe he can
> explain why :)

What I prefer is something that 1) can be identified as a synthetic signature and 2) doesn't clash with something that could appear otherwise. "mozalloc_abort" fails both those rules. Right now we get "EMPTY: no crashing thread identified; corrupt dump" so I think leaning on the rule that we're using a prefix of "EMPTY: " for synthetic signatures where we don't have a good stack is reasonable. What we put behind that prefix is whatever you like, but inventing frames that may not actually be correct is IMHO a bad idea.

Comment 2

[Jesse Ruderman]

How about "mozalloc_abort | EMPTY"?

Why would the frame be incorrect? If OOMAllocationSize is set, it's set by mozalloc_abort.

Comment 3

[Jesse Ruderman]

Having a fix for this would improve user support.  Most helpers aren't scrolling down when they see "[@ EMPTY: no crashing thread identified; corrupt dump ]".

Comment 4

[Lonnen :lonnen]

if still desired reopen or file new and we may be able to go implement as a processor rule