Crash [@ RuleHash_ClassTable_GetKey] with DOMi manipulating hidden menubar

RESOLVED DUPLICATE of bug 343508

Status

()

Core
CSS Parsing and Computation
--
critical
RESOLVED DUPLICATE of bug 343508
10 years ago
7 years ago

People

(Reporter: wildmyron, Unassigned)

Tracking

({crash, testcase})

Trunk
x86
Windows XP
crash, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ccbr], crash signature)

Attachments

(3 attachments)

(Reporter)

Description

10 years ago
Created attachment 315712 [details]
Popup window without menubar

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008041406 Minefield/3.0pre ID:2008041406

STR:
1) Install DOMi
2) open attached testcase and click link to open a window with no menubar
3) open DOMi and inspect the chrome of the popup window
4) Find node by id: toolbar-menubar
5) go to the CSS Style Rules view
6) view the |window[chromehidden~="menubar"]...| rule
7) delete the display:none property
8) in the left pane: click the id=nav-bar node (or some other node)
9) click the id=toolbar-menubar node

Result: crash

bp-257ad8cf-0aaa-11dd-93e8-001321b13766
Frame  	Module  	Signature [Expand]  	Source
0 	xul.dll 	RuleHash_ClassTable_GetKey 	mozilla/layout/style/nsCSSRuleProcessor.cpp:212
1 	xul.dll 	RuleHash_CSMatchEntry 	mozilla/layout/style/nsCSSRuleProcessor.cpp:194
2 	xul.dll 	RuleHash::EnumerateAllRules 	mozilla/layout/style/nsCSSRuleProcessor.cpp:597
3 	xul.dll 	nsINode::IsEditableInternal

also crashes in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060407 Firefox/3.0a1

Martijn: I know you are really good with automated testcases and wonder if you can come up with a way to do something similar from privileged script which would also crash.
(Reporter)

Comment 1

10 years ago
Created attachment 315713 [details]
better stack from WinDBG
Created attachment 316079 [details]
testcase, using enhanced privileges

Ok, I think this is basically the same crash.
The toggle() function isn't really necessary, it just might quicken the crash. But opening a new Firefox instance triggers the crash too.

I'm seeing this js error in the error console, with the testcase.
Error: uncaught exception: [Exception... "Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIDOMCSSStyleDeclaration.removeProperty]"  nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)"  location: "JS frame :: file:///C:/Documents%20and%20Settings/mw/Bureaublad/removeallrules.htm :: doe :: line 32"  data: no]

So it seems like removeProperty isn't successful, but after that the toolbar-menubar can become visible again, so it seems like that is the cause of the crash, somehow.
From: http://crash-stats.mozilla.com/report/index/3e53f1fd-0bd6-11dd-b3d7-001cc45a2ce4
0  	xul.dll  	RuleHash_ClassTable_GetKey  	 mozilla/layout/style/nsCSSRuleProcessor.cpp:213
1 	xul.dll 	RuleHash_CSMatchEntry 	mozilla/layout/style/nsCSSRuleProcessor.cpp:195
2 	xul.dll 	RuleHash::EnumerateAllRules 	mozilla/layout/style/nsCSSRuleProcessor.cpp:598
3 	xul.dll 	XPC_WN_Shared_Proto_Finalize 	
Keywords: testcase
Summary: Crash with DOMi manipulating hidden menubar → Crash [@ RuleHash_ClassTable_GetKey] with DOMi manipulating hidden menubar
I'm seeing this assertion in a debug build just before the js error:
###!!! ASSERTION: container didn't take ownership: 'Not Reached', file c:/mozilla-build/mozilla/layout/style/nsCSSStyleRule.cpp, line 996

I guess this is related to bug 343508.
Depends on: 343508
Whiteboard: [ccbr]

Comment 5

9 years ago
Just had this too - http://crash-stats.mozilla.com/report/index/bp-550e8d3e-df72-40c1-a8cc-3b6cb2091008
0  	seamonkey.exe  	RuleHash_ClassTable_GetKey  	 layout/style/nsCSSRuleProcessor.cpp:222
1 	seamonkey.exe 	RuleHash_CSMatchEntry 	layout/style/nsCSSRuleProcessor.cpp:204
2 	xpcom_core.dll 	SearchTable 	objdir/mozilla/xpcom/build/pldhash.c:423
3 	xpcom_core.dll 	PL_DHashTableOperate 	objdir/mozilla/xpcom/build/pldhash.c:609
The testcase doesn't seem to crash anymore, using:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091229 Minefield/3.7a1pre
So I guess this might have been fixed by bug 343508.
Ah, this was in fact fixed by bug 536379. It seems like the same bug, even.
Depends on: 536379
No longer depends on: 343508
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 343508
(Assignee)

Updated

7 years ago
Crash Signature: [@ RuleHash_ClassTable_GetKey]
You need to log in before you can comment on or make changes to this bug.