637165 - Crash [@ mozalloc_abort(char const* const) | mozalloc_handle_oom() | nsTArray_base<nsTArrayDefaultAllocator>::EnsureCapacity(unsigned int, unsigned int) | nsCSSRuleProcessor::RefreshRuleCascade(nsPresContext*) ]

Status: RESOLVED INCOMPLETE

(Core :: CSS Parsing and Computation, defect)

Description

[Scoobidiver (away)]

It is probably a dupe of bug 627706.

Signature	mozalloc_abort(char const* const) | mozalloc_handle_oom() | nsTArray_base<nsTArrayDefaultAllocator>::EnsureCapacity(unsigned int, unsigned int) | nsCSSRuleProcessor::RefreshRuleCascade(nsPresContext*)
UUID	58ae305f-6c37-4c64-a2a9-50fc52110227
Time 	2011-02-27 05:59:35.848838
Uptime	323
Last Crash	325 seconds (5.4 minutes) before submission
Install Age	23107 seconds (6.4 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	0x74261a39
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 	nsTArray_base<nsTArrayDefaultAllocator>::EnsureCapacity 	obj-firefox/dist/include/nsTArray-inl.h:106
3 	xul.dll 	nsCSSRuleProcessor::RefreshRuleCascade 	layout/style/nsCSSRuleProcessor.cpp:3148
4 	xul.dll 	nsCSSRuleProcessor::RulesMatching 	layout/style/nsCSSRuleProcessor.cpp:2442
5 	xul.dll 	EnumRulesMatching<AnonBoxRuleProcessorData> 	layout/style/nsStyleSet.cpp:406
6 	xul.dll 	nsStyleSet::FileRules 	layout/style/nsStyleSet.cpp:621
7 	xul.dll 	nsStyleSet::ResolveAnonymousBoxStyle 	layout/style/nsStyleSet.cpp:975
8 	xul.dll 	nsCSSFrameConstructor::ConstructRootFrame 	layout/base/nsCSSFrameConstructor.cpp:2539
9 	xul.dll 	PresShell::InitialReflow 	layout/base/nsPresShell.cpp:2707
10 	xul.dll 	nsContentSink::StartLayout 	content/base/src/nsContentSink.cpp:1241
11 	xul.dll 	nsHtml5TreeOpExecutor::StartLayout 	parser/html/nsHtml5TreeOpExecutor.cpp:668
12 	xul.dll 	nsHtml5TreeOperation::Perform 	parser/html/nsHtml5TreeOperation.cpp:708
13 	xul.dll 	nsHtml5TreeOpExecutor::RunFlushLoop 	parser/html/nsHtml5TreeOpExecutor.cpp:509
14 	xul.dll 	nsHtml5ExecutorReflusher::Run 	parser/html/nsHtml5StreamParser.cpp:153
15 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:633
16 	xul.dll 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:110
17 	xul.dll 	xul.dll@0xb2f7a7 	
18 	xul.dll 	MessageLoop::RunInternal 	ipc/chromium/src/base/message_loop.cc:219
19 	xul.dll 	MessageLoop::RunHandler 	ipc/chromium/src/base/message_loop.cc:202
20 	mozcrt19.dll 	_VEC_memzero 	
21 	xul.dll 	xul.dll@0x359b4d 	
22 	firefox.exe 	firefox.exe@0x1bb7 	
23 	ntdll.dll 	ntdll.dll@0x1d554 	
24 	ntdll.dll 	ntdll.dll@0x5b3fb 	
25 	firefox.exe 	firefox.exe@0x186f 	
26 	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|%20nsTArray_base%3CnsTArrayDefaultAllocator%3E%3A%3AEnsureCapacity%28unsigned%20int%2C%20unsigned%20int%29%20|%20nsCSSRuleProcessor%3A%3ARefreshRuleCascade%28nsPresContext*%29

Comment 2

[Boris Zbarsky [:bzbarsky]]

This is an OOM crash on AddRule trying to resize arrays.  I supposed if we care about keeping AddRule fallible we should make these arrays also fallible....

Comment 3

[Robert Kaiser]

We suddenly have a whole lot of "mozalloc_abort(char const* const) | mozalloc_handle_oom() |" crashes rising significantly since we released 4.0.1, are those likely to be related?

Comment 4

[Bob Clary [:bc] (inactive)]

I've seen this on Windows XP and 7 with oom and similar stacks beginning with

mozalloc_abort(char const* const) | mozalloc_handle_oom() | nsTArray_base<nsTArrayDefaultAllocator>::EnsureCapacity(unsigned int, unsigned int)

on 41 different urls. When reproducing, the stack can vary depending on where it runs out.

Example: http://www.rentcaravan.com/haz-tu-reserva.php?accion=calcular The page is many megabytes of server side generated error messages.

Example: http://micro.msi.com/oc/teams_dk.php The page is again many megabytes of server side generated error messages.

Comment 5

[Scoobidiver (away)]

(In reply to comment #4)
> Example: http://www.rentcaravan.com/haz-tu-reserva.php?accion=calcular
> Example: http://micro.msi.com/oc/teams_dk.php
It is not exactly the same crash signature because these crashes implicate the HTML5 component and not the CSS one.

Comment 6

[Carsten Book [:Tomcat]]

(In reply to Bob Clary [:bc:] from comment #4)
> I've seen this on Windows XP and 7 with oom and similar stacks beginning with
> 
> mozalloc_abort(char const* const) | mozalloc_handle_oom() |
> nsTArray_base<nsTArrayDefaultAllocator>::EnsureCapacity(unsigned int,
> unsigned int)
> 
> on 41 different urls. When reproducing, the stack can vary depending on
> where it runs out.
> 
> Example: http://www.rentcaravan.com/haz-tu-reserva.php?accion=calcular The
> page is many megabytes of server side generated error messages.
> 
> Example: http://micro.msi.com/oc/teams_dk.php The page is again many
> megabytes of server side generated error messages.

still reproducible oom like out of memory: 0x000000001FF00000 bytes requested
Hit MOZ_CRASH() at c:/Users/mozilla/debug-builds/mozilla-central/memory/mozalloc/mozalloc_abort.cpp:33

Comment 7

[Mats Palmgren (inactive)]

nsCSSRuleProcessor is gone so it's not worth tracking these signatures anymore.
Please file new bugs as appropriate.