958091 - OOM crash in GCGraphBuilder::GCGraphBuilder(nsCycleCollector*, GCGraph&, mozilla::CycleCollectedJSRuntime*, nsICycleCollectorListener*, bool)

Status: RESOLVED WORKSFORME

(Core :: XPCOM, defect)

Description

[Tracy Walker [:tracy]]

This bug was filed from the Socorro interface and is 
report bp-e215b3b2-7e09-4db7-8293-704a02140108.
=============================================================

This has been hanging around ~#15 on Fx26.0 and 27.0betas topcrash reports.

Comment 1

[Andrew McCreight [:mccr8]]

I looked at a few of these, and they are all happening when PL_DHashTableInit fails, which I assume means the allocation failed.  In the reports I looked at, system memory usage was anywhere from 70% to 96%, so I think there's some combination of memory fragmentation and low memory to blame.  I'm not sure if I can really do anything.  The default size is 32768, which is maybe a little large, but if we're unable to allocate that much, I'm not sure if the CC will be able to finish doing anything interesting.

Comment 2

[Tracy Walker [:tracy]]

I just had a conversation with bsmedberg about an entire group of OOM crashes on our topcrash lists.  He said, 'really "need to figure out why the user is out of memory." which is a really hard problem, not something that we can track via crash-stats probably.'  Decided to not file bugs on those signatures.

He also agreed this bug is similar to those variations of mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) in crash stats. In those, there is some sort of memory fragmentation and/or oom. Given that, this bug, at worst is invalid, at best, a depends on a bug for a solution to OOM.

Comment 3

[Andrew McCreight [:mccr8]]

It might be nice to trigger a different crash so the signature looks more like an OOM, or something.

Comment 4

[Julien Wajsberg [:julienw]]

In case this helps, a friend of mine gets both this crash (crash report af169b32-f01e-4761-84d6-7085d2140121) and the crash in a570c868-618c-416a-a5c0-60f5b2140121 which looks like a memory issue as well on the same environment. She can try things if this is needed.

Comment 5

[Andrew McCreight [:mccr8]]

Yeah, if she is getting OOMy crashes frequently it might be useful.  You could ask bsmedberg or dmajor for suggestions.

Comment 6

[Julien Wajsberg [:julienw]]

She's mainly seeing the crash after leaving Firefox running during a long time (eg: a night). So I suspect a bad website, but this is quite new for her too.

I already asked her a about:memory dump from a long-running session so we'll see.

Comment 7

[Julien Wajsberg [:julienw]]

She just got another crash: https://crash-stats.mozilla.com/report/index/1ef683cb-f6f9-4f1e-b60e-9e6c22140203

Comment 8

[Gary O'Donnell]

I can confirm that this occurs when memory utilization by Firefox is high.  Two crash reports with this signature (see below) were generated on a machine running 32-bit Windows 7 by intentionally performing repetitive actions that cause memory to be consumed (I'm tracking down a suspected resource leak in a web app).

The breaking point appears to be where Firefox is using around 1.3GB, which I know is quite possibly at the extreme of what is available to it in a 32 bit OS.

The first crash report is with no other applications running; the second is where Excel had pushed up consumption of physical memory to around 85%.  In both cases, the crash occurred when Firefox had consumed around 1.3GB, thus indicating that actual utilization by Firefox is the issue and not total system utilization.

https://crash-stats.mozilla.com/report/index/a04927c3-9628-411b-ad32-2dd872140625
https://crash-stats.mozilla.com/report/index/fd2b356e-09d6-46b1-a934-82ab32140625

Comment 9

[Robert Kaiser]

Hmm, if this is OOM, we should annotate the OOM allocation size so our mechanisms to detect OOM on crash-stats can catch that decently.

Andrew, is it you who's need to work on that, or someone else? bsmedberg can tell you how exactly to annotate this correctly.

Comment 10

[Andrew McCreight [:mccr8]]

Yes, I already did that 4 months ago in bug 962608 for almost every instance of PL_DHashTableInit in the browser. ;)  That landed in Firefox 30, and the crashes in comment 8 are from Firefox 27.

Comment 11

[Andrew McCreight [:mccr8]]

This signature shouldn't happen any more on Firefox 30 and later, and I don't see it either.

Comment 12

[Robert Kaiser]

(In reply to Andrew McCreight [:mccr8] from comment #10)
> Yes, I already did that 4 months ago in bug 962608 for almost every instance
> of PL_DHashTableInit in the browser. ;)  That landed in Firefox 30, and the
> crashes in comment 8 are from Firefox 27.

Oh, sorry, just saw the new comment with crashes and didn't look at their Firefox version. Thanks for the implementation! :)