Closed Bug 864344 Opened 7 years ago Closed 7 years ago

stop pretending the cycle collector handles malloc failure

Categories

(Core :: XPCOM, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla23

People

(Reporter: mccr8, Assigned: mccr8)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Apparently NS_Alloc is infallible, which is good because the supposed handling of OOMs just stops building the graph and proceeds with the CC, which could cause live objects to be unlinked if we haven't finished tracing all JS.  In the short term, it is probably better to remove that weird unused recovery code.
xpcom/base/nsCycleCollector.cpp:506 is one relevant NS_Alloc call (see bug 862592), though there may be others.
Yeah, the one Nick found that allocates a lot of stuff is for node blocks.  It looks like that's the only one, probably because that was the largest allocation.
Note that GCGraphBuilder::AddNode can still fail, if the hash table add fails.  That makes me a bit nervous, but I guess I'll leave it alone for now.
Assignee: nobody → continuation
Attachment #742542 - Flags: review?(bugs) → review+
https://hg.mozilla.org/mozilla-central/rev/65a8c128edba
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla23
(In reply to Andrew McCreight [:mccr8] from comment #3)
> Created attachment 742542 [details] [diff] [review]
> remove NS_Alloc error handling code
> 
> Note that GCGraphBuilder::AddNode can still fail, if the hash table add
> fails.  That makes me a bit nervous, but I guess I'll leave it alone for now.

Could you fix this?  I've seen a failure mode lately where I run out of virtual address space in the middle of cycle collection and fail to grow the hashtable, which means each attempt to add to that hashtable makes a syscall and rather than crash the browser just hangs trying to allocate new pages of memory hundreds of millions of times.
You need to log in before you can comment on or make changes to this bug.