Last Comment Bug 761086 - crash in inDOMUtils::GetRuleNodeForContent @ nsINode::IsElement with Inspector
: crash in inDOMUtils::GetRuleNodeForContent @ nsINode::IsElement with Inspector
Status: RESOLVED FIXED
[qa?]
: crash, regression
Product: Core
Classification: Components
Component: Layout (show other bugs)
: 15 Branch
: All Windows 7
: -- critical (vote)
: mozilla16
Assigned To: Boris Zbarsky [:bz]
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-04 01:38 PDT by Scoobidiver (away)
Modified: 2012-08-28 02:52 PDT (History)
6 users (show)
bzbarsky: in‑testsuite?
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
+
fixed


Attachments
Fix (1.05 KB, patch)
2012-06-05 19:22 PDT, Boris Zbarsky [:bz]
bugs: review+
akeybl: approval‑mozilla‑aurora+
Details | Diff | Review

Description Scoobidiver (away) 2012-06-04 01:38:41 PDT
It first appeared in 15.0a1/20120507. The regression range might be (discontinuous):
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=94ce5f33a9ea&tochange=448f554f6acb

All comments talk about the element inspector.

Signature 	nsINode::IsElement() More Reports Search
UUID	19681c62-263f-4e27-8682-709602120604
Date Processed	2012-06-04 03:47:37
Uptime	32012
Last Crash	3.6 days before submission
Install Age	13.7 hours since version was first installed.
Install Time	2012-06-03 14:03:57
Product	Firefox
Version	15.0a1
Build ID	20120603030523
Release Channel	nightly
OS	Windows NT
OS Version	6.1.7601 Service Pack 1
Build Architecture	x86
Build Architecture Info	GenuineIntel family 6 model 37 stepping 2
Crash Reason	EXCEPTION_ACCESS_VIOLATION_READ
Crash Address	0x18
App Notes 	
AdapterVendorID: 0x8086, AdapterDeviceID: 0x0046, AdapterSubsysID: 215a17aa, AdapterDriverVersion: 8.15.10.2401
D2D? D2D+ DWrite? DWrite+ D3D10 Layers? D3D10 Layers+ WebGL? EGL? EGL+ GL Context? GL Context+ WebGL+ 
EMCheckCompatibility	True	
Total Virtual Memory	4294836224
Available Virtual Memory	3044982784
System Memory Use Percentage	58
Available Page File	3805892608
Available Physical Memory	1676779520

Frame 	Module 	Signature 	Source
0 	xul.dll 	nsINode::IsElement 	obj-firefox/dist/include/nsINode.h:368
1 	xul.dll 	inDOMUtils::GetRuleNodeForContent 	layout/inspector/src/inDOMUtils.cpp:295
2 	xul.dll 	inDOMUtils::GetCSSStyleRules 	layout/inspector/src/inDOMUtils.cpp:170
3 	xul.dll 	NS_InvokeByIndex_P 	xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:70
4 	xul.dll 	XPCWrappedNative::CallMethod 	js/xpconnect/src/XPCWrappedNative.cpp:2356
5 	xul.dll 	XPC_WN_CallMethod 	js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1500
6 	mozjs.dll 	js::InvokeKernel 	js/src/jsinterp.cpp:310
7 	mozjs.dll 	js::Interpret 	js/src/jsinterp.cpp:2512
8 	mozjs.dll 	js::CallObject::createForFunction 	js/src/vm/ScopeObject.cpp:199
9 	mozjs.dll 	js::Invoke 	js/src/jsinterp.cpp:358
...

More reports at:
https://crash-stats.mozilla.com/report/list?signature=nsINode%3A%3AIsElement%28%29
Comment 1 Boris Zbarsky [:bz] 2012-06-04 11:28:57 PDT
I can (and should) certainly fix this on the layout end by null-checking the element in inDOMUtils::GetCSSStyleRules and throwing when null, but why is the element inspector passing in null, exactly?  Throwing will likely break whatever element inspector code is passing null.

I guess it's also possible that the element inspector is passing some random non-DOM JS object, not null.
Comment 2 Mihai Sucan [:msucan] 2012-06-04 11:31:04 PDT
Paul: this is something related to the Inspector. Can you please take a look? Thanks!
Comment 3 Boris Zbarsky [:bz] 2012-06-05 19:22:45 PDT
Created attachment 630416 [details] [diff] [review]
Fix

Well, let's just throw instead of crashing
Comment 5 Boris Zbarsky [:bz] 2012-06-06 13:06:31 PDT
Comment on attachment 630416 [details] [diff] [review]
Fix

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Probably landing of some inspector
   changes
User impact if declined: Crashes in some circumstances that I don't understand
Testing completed (on m-c, etc.):  None.  The patch just adds a null-check on the   crashing codepath.
Risk to taking this patch (and alternatives if risky): Low risk: just a
   null-check.  Might replace crashes with the inspector tool not working right
   in some edge case, perhaps.
String or UUID changes made by this patch: None.
Comment 6 Ed Morley [:emorley] 2012-06-07 05:49:14 PDT
https://hg.mozilla.org/mozilla-central/rev/41838b80cb57
Comment 7 Alex Keybl [:akeybl] 2012-06-11 12:49:12 PDT
Comment on attachment 630416 [details] [diff] [review]
Fix

[Triage Comment]
Low risk null check. Approved for Aurora 15.
Comment 9 Ioana (away) 2012-08-10 04:50:38 PDT
Verified the crash stats on the Socorro interface 
https://crash-stats.mozilla.com/report/list?query_search=signature&query_type=contains&reason_type=contains&range_value=1&range_unit=weeks&hang_type=any&process_type=any&signature=nsINode%3A%3AIsElement%28%29.

It seems that crashes with this signature are still happening, but they are also associated to bug 772459 (which has not been fixed yet). Are there any STR/guidelines QA can verify this fix with?

Note You need to log in before you can comment on or make changes to this bug.