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

Status: RESOLVED WORKSFORME

(Core :: DOM: HTML Parser, defect)

Description

[Scoobidiver (away)]

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

Comment 1

[Henri Sivonen (:hsivonen) (temporarily away from Bugzilla)]

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?

Comment 2

[Scoobidiver (away)]

> 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.

Comment 3

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

mozalloc doesn't exist in 1.9.2.

Comment 4

[Henri Sivonen (:hsivonen) (temporarily away from Bugzilla)]

(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?

Comment 5

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

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.

Comment 6

[Marcia Knous [:marcia]]

Adding the Mac specific signature.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 8

[Andrei Purice]

Following the reporter's steps I am able to confirm that the issues doesn't happen anymore on Windows 10x64 and MacOS 10.15 on any of the current versions of Firefox Nightly 87.0a1 (2021-02-22), beta 86.0 and release 85.0.2. No crashes occur under the given test case.

Closing this issue as Resolved > Worksforme.
Feel free to re-open or file a new bug if this issue reoccurs again.