637166 - Crash [@ mozalloc_abort(char const* const) | mozalloc_handle_oom() | std::_Allocate<MessageLoop::PendingTask>(unsigned int, MessageLoop::PendingTask*) ]

Status: RESOLVED WONTFIX

(Core :: IPC, defect)

Description

[Scoobidiver (away)]

It is a new crash signature that first appeared in 4.0b11.

Signature	mozalloc_abort(char const* const) | mozalloc_handle_oom() | std::_Allocate<MessageLoop::PendingTask>(unsigned int, MessageLoop::PendingTask*)
UUID	6a865c05-7b2c-4c14-88e2-68ab02110227
Time 	2011-02-27 05:46:00.319275
Uptime	54
Last Crash	76 seconds before submission
Install Age	22292 seconds (6.2 hours) since version was first installed.
Product	Firefox
Version	4.0b12
Build ID	20110222210221
Branch	2.0
OS	Windows NT
OS Version	6.1.7600
CPU	x86
CPU Info	GenuineIntel family 6 model 22 stepping 1
Crash Reason	EXCEPTION_BREAKPOINT
Crash Address	0x741e1a39
App Notes 	AdapterVendorID: 10de, AdapterDeviceID: 0291, AdapterDriverVersion: 8.15.11.8593

Frame 	Module 	Signature [Expand] 	Source
0 	mozalloc.dll 	mozalloc_abort 	memory/mozalloc/mozalloc_abort.cpp:77
1 	mozalloc.dll 	mozalloc_handle_oom 	memory/mozalloc/mozalloc_oom.cpp:54
2 	xul.dll 	std::_Allocate<MessageLoop::PendingTask> 	xmemory:44
3 	xul.dll 	std::deque<MessageLoop::PendingTask,std::allocator<MessageLoop::PendingTask> >::push_back 	deque:825
4 	xul.dll 	std::deque<MessageLoop::PendingTask,std::allocator<MessageLoop::PendingTask> >::_Insert<std::_Deque_const_iterator<MessageLoop::PendingTask,std::allocator<MessageLoop::PendingTask>,1> > 	deque:1008
5 	xul.dll 	std::deque<MessageLoop::PendingTask,std::allocator<MessageLoop::PendingTask> >::insert<std::_Deque_const_iterator<MessageLoop::PendingTask,std::allocator<MessageLoop::PendingTask>,1> > 	deque:928
6 	xul.dll 	std::deque<MessageLoop::PendingTask,std::allocator<MessageLoop::PendingTask> >::deque<MessageLoop::PendingTask,std::allocator<MessageLoop::PendingTask> > 	deque:562
7 	xul.dll 	std::swap<std::queue<MessageLoop::PendingTask,std::deque<MessageLoop::PendingTask,std::allocator<MessageLoop::PendingTask> > > > 	utility:18
8 	xul.dll 	MessageLoop::DoWork 	ipc/chromium/src/base/message_loop.cc:437
9 	xul.dll 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:114
10 	xul.dll 	xul.dll@0xb2f7a7 	
11 	xul.dll 	MessageLoop::RunInternal 	ipc/chromium/src/base/message_loop.cc:219
12 	xul.dll 	MessageLoop::RunHandler 	ipc/chromium/src/base/message_loop.cc:202
13 	mozcrt19.dll 	_VEC_memzero 	
14 	xul.dll 	xul.dll@0x359b4d 	
15 	firefox.exe 	firefox.exe@0x1bb7 	
16 	ntdll.dll 	ntdll.dll@0x1d554 	
17 	ntdll.dll 	ntdll.dll@0x5b3fb 	
18 	firefox.exe 	firefox.exe@0x186f 	
19 	firefox.exe 	firefox.exe@0x186f

More reports at:
https://crash-stats.mozilla.com/report/list?range_value=4&range_unit=weeks&signature=mozalloc_abort%28char%20const*%20const%29%20|%20mozalloc_handle_oom%28%29%20|%20std%3A%3A_Allocate%3CMessageLoop%3A%3APendingTask%3E%28unsigned%20int%2C%20MessageLoop%3A%3APendingTask*%29

Comment 1

[Boris Zbarsky [:bzbarsky]]

Looks like an OOM crash.

Comment 2

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

Yeah, definitely.  A random sample of the crash URLs were almost all from the same site.  I'll take a look later.

Comment 3

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

Observations so far, testing with the 2/28 nightly on win7 with GPU rendering forced off
 - the crashing page uses a lot of memory in the plugin-container process; ~20MB per tab or so.  If there are a lot of these tabs open, system memory usage will be high.
 - the page uses ~4MB per tab or so in firefox-bin
 - the memory used in plugin-container is pretty stable
 - (very interestingly) after a while, the memory usage of firefox-bin starts growing by ~20KB/sec or so.  I don't have a precise measurement.
 - the growth continues without an apparent bound: I let it go past 50MB in one trial
 - opening a new tab, about:memory in my tests, reclaims all the growth.  So the memory isn't leaking.
 - the memory reclaimed isn't in the JS heap, at least not according to about:memory; the usage before/after reclamation is about the same
 - this *doesn't* happen on my linux desktop.  (Local debug build though, not sure if that matters.)  Sigh, can't use massif.
 - all the IPC traffic in the steady state is plugin-layer publishing, no NPRuntime stuff or anything

This page is updating a couple of flash instances at a pretty high rate.  I wonder if that's somehow messing up cycle-collector heuristics or something.  I'm not set up to grab a heap profile on win7, but I can try that later if no one has ideas or gets more info in the meantime.

Comment 4

[Boris Zbarsky [:bzbarsky]]

You can set the "javascript.options.mem.log" preference to have GC and CC events logged to your error console, with some information about how much the latter has collected.  Worth checking that these correlate with your memory reclamation.

Comment 5

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

They do, but don't really shed light on what's happening.  I let the page run up about 15MB of bloat over 10 minutes or so.  During that time I saw

CC timestamp: XXX, collected 0, suspected ~1150, duration ~13ms

This happened 28 times.  No GCs in there.  Then I opened about:blank, saw a GC, then a CC with "collected 315, suspected 1014", another GC, and another CC.  Somewhere during that time the 15MB of garbage was reclaimed.  I wonder if there's memory that's only reclaimable during GC, but not counted in the GC heap.  Or something.

Comment 6

[Scoobidiver (away)]

It is #32 top crasher in 4.0b12.

Comment 7

[Boris Zbarsky [:bzbarsky]]

> I wonder if there's memory that's only reclaimable during GC, but not counted
> in the GC heap.

Quite possible.  I think the JS folks are trying to stop that happening...

Comment 8

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

Bug 637279 has CC'd the author of the code that's apparently causing bad things to happen, so probably better to prefer that bug.

Comment 9

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

This should be an easy test case for heap analysis tools.

Comment 10

[Andrew McCreight [:mccr8]]

Comment 5 (cycle collector running, not collecting anything, then the GC runs, then the CC collects a bunch of stuff) would happen if there are cycles rooted by JS objects.

Comment 11

[Sylvestre Ledru [:Sylvestre]]

Closing because no crash reported since 12 weeks.