Open Bug 603079 Opened 10 years ago Updated 4 years ago

crash mainly at start-up [@ nsHtml5AttributeName::initializeStatics() ]

Categories

(Core :: DOM: HTML Parser, defect)

defect
Not set
critical

Tracking

()

Tracking Status
firefox47 --- affected
firefox48 --- affected
firefox49 --- affected
firefox-esr45 --- affected
firefox50 --- affected

People

(Reporter: scoobidiver, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: crash, Whiteboard: [startupcrash])

Crash Data

It is a residual crash signature that exist in 3.6.x (x<9) and trunk builds.
It happens mainly at start-up.
It is #37 top crasher in b8pre/20101008 build.

Signature	nsHtml5AttributeName::initializeStatics()
UUID	e3aff140-06dd-45c0-a3c8-079402101008
Time 	2010-10-08 19:18:14.958519
Uptime	1
Last Crash	11468 seconds (3.2 hours) before submission
Install Age	36117 seconds (10.0 hours) since version was first installed.
Product	Firefox
Version	4.0b8pre
Build ID	20101008041525
Branch	2.0
OS	Windows NT
OS Version	5.1.2600 Service Pack 3
CPU	x86
CPU Info	GenuineIntel family 6 model 23 stepping 10
Crash Reason	EXCEPTION_ACCESS_VIOLATION_READ
Crash Address	0x10d989b4

Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	nsHtml5AttributeName::initializeStatics 	parser/html/nsHtml5AttributeName.cpp:555
1 	xul.dll 	nsHtml5Module::InitializeStatics 	parser/html/nsHtml5Module.cpp:66
2 	xul.dll 	nsLayoutStatics::Initialize 	layout/build/nsLayoutStatics.cpp:278
3 	xul.dll 	Initialize 	layout/build/nsLayoutModule.cpp:389
4 	xul.dll 	nsComponentManagerImpl::KnownModule::Load 	xpcom/components/nsComponentManager.cpp:961
5 	xul.dll 	nsFactoryEntry::GetFactory 	xpcom/components/nsComponentManager.cpp:1936
6 	xul.dll 	xul.dll@0xbeb24b 	
7 	xul.dll 	nsComponentManagerImpl::CreateInstanceByContractID 	xpcom/components/nsComponentManager.cpp:1299
8 	xul.dll 	nsComponentManagerImpl::GetServiceByContractID 	xpcom/components/nsComponentManager.cpp:1664
9 	xul.dll 	nsCOMPtr_base::assign_from_gs_contractid 	obj-firefox/xpcom/build/nsCOMPtr.cpp:132
10 	xul.dll 	nsChromeRegistryChrome::ManifestContent 	chrome/src/nsChromeRegistryChrome.cpp:879
11 	xul.dll 	ParseManifestCommon 	xpcom/components/ManifestParser.cpp:622
12 	xul.dll 	ParseManifest 	xpcom/components/ManifestParser.cpp:660
13 	xul.dll 	nsComponentManagerImpl::RegisterJarManifest 	xpcom/components/nsComponentManager.cpp:594
14 	xul.dll 	nsComponentManagerImpl::ManifestManifest 	xpcom/components/nsComponentManager.cpp:691
15 	xul.dll 	ParseManifestCommon 	xpcom/components/ManifestParser.cpp:633
16 	xul.dll 	ParseManifest 	xpcom/components/ManifestParser.cpp:660
17 	xul.dll 	nsComponentManagerImpl::RegisterJarManifest 	xpcom/components/nsComponentManager.cpp:594
18 	xul.dll 	nsComponentManagerImpl::Init 	xpcom/components/nsComponentManager.cpp:403
19 	xul.dll 	NS_InitXPCOM2_P 	xpcom/build/nsXPComInit.cpp:523
20 	xul.dll 	ScopedXPCOMStartup::Initialize 	toolkit/xre/nsAppRunner.cpp:1188
21 	xul.dll 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3434
22 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp:120
23 	firefox.exe 	__tmainCRTStartup 	obj-firefox/memory/jemalloc/crtsrc/crtexe.c:591
24 	kernel32.dll 	BaseProcessStart 

More reports at:
http://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=exact&query=&range_value=2&range_unit=weeks&hang_type=any&process_type=any&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=nsHtml5AttributeName%3A%3AinitializeStatics%28%29
This looks like bug 538722.

> It happens mainly at start-up.

Does it ever happen on non-startup? How?

If this is Firefox running out of memory at startup, why isn't the infallible malloc killing the process?
> This looks like bug 538722.
This bug was fixed in 1.9.2.9 by making the HTML5 parser not participate at run time without removing all the code, with more context.
It is a workaround and not a valid fix for trunk build.

> Does it ever happen on non-startup? How?
I will say more than 95% of crashes happens at start-up.
mozalloc doesn't exist in 1.9.2.
(In reply to comment #3)
> mozalloc doesn't exist in 1.9.2.

What about the 4.0 beta crashes? Such as the one in comment 0?
Dunno.  That doesn't look like OOM since it's reading from a garbage pointer instead of NULL.  Could try stepping through the new() calls there to ensure they're going through mozalloc.  Other than that, not enough info for other hypotheses.
Crash Signature: [@ nsHtml5AttributeName::initializeStatics() ]
Adding the Mac specific signature.
Crash Signature: [@ nsHtml5AttributeName::initializeStatics() ] → [@ nsHtml5AttributeName::initializeStatics() ] [@ nsHtml5AttributeName::initializeStatics ]
OS: Windows XP → All
Hardware: x86 → All
Blocks: 609497
Whiteboard: [startupcrash]
Crash volume for signature 'nsHtml5AttributeName::initializeStatics':
 - nightly (version 50): 1 crash from 2016-06-06.
 - aurora  (version 49): 11 crashes from 2016-06-07.
 - beta    (version 48): 190 crashes from 2016-06-06.
 - release (version 47): 349 crashes from 2016-05-31.
 - esr     (version 45): 25 crashes from 2016-04-07.

Crash volume on the last weeks:
             Week N-1   Week N-2   Week N-3   Week N-4   Week N-5   Week N-6   Week N-7
 - nightly          1          0          0          0          0          0          0
 - aurora           0          0          0         11          0          0          0
 - beta            34         22         19         59         25         26          1
 - release         49         38         52         52         68         46         23
 - esr              0          0          1          0          0          0          0

Affected platforms: Windows, Mac OS X, Linux
You need to log in before you can comment on or make changes to this bug.