Crash [@ nsURIHashKey::HashKey] with -moz-element in data: document

RESOLVED FIXED in mozilla2.0b7

Status

()

--
critical
RESOLVED FIXED
8 years ago
7 years ago

People

(Reporter: jruderman, Assigned: mstange)

Tracking

(Blocks: 2 bugs, {crash, testcase})

Trunk
mozilla2.0b7
x86
Mac OS X
crash, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(blocking2.0 final+)

Details

(crash signature)

Attachments

(2 attachments)

(Reporter)

Description

8 years ago
Created attachment 468934 [details]
testcase (crashes Firefox when loaded)
http://crash-stats.mozilla.com/report/index/8509f81f-5a41-4d92-9fba-dd51e2100826
0  	xul.dll  	nsURIHashKey::HashKey  	 obj-firefox/dist/include/nsURIHashKey.h:74
1 	xul.dll 	nsTHashtable<nsBaseHashtableET<nsURIHashKey,nsCOMPtr<nsIStreamListener> > >::s_HashKey 	obj-firefox/dist/include/nsTHashtable.h:365
2 	xul.dll 	PL_DHashTableOperate 	obj-firefox/xpcom/build/pldhash.c:615
3 	xul.dll 	nsTHashtable<nsBaseHashtableET<PrincipalKey,nsCOMPtr<nsIPrincipal> > >::GetEntry 	obj-firefox/dist/include/nsTHashtable.h:170
4 	xul.dll 	nsRefPtrHashtable<nsPtrHashKey<void const >,nsAccessible>::GetWeak 	obj-firefox/dist/include/nsRefPtrHashtable.h:143
5 	xul.dll 	GetEffectPropertyForURI 	layout/svg/base/src/nsSVGEffects.cpp:397
6 	xul.dll 	ImageRenderer::PrepareImage 	
7 		@0x251f9a77 	
8 	xul.dll 	nsCSSRendering::PaintBackgroundWithSC 	layout/base/nsCSSRendering.cpp:2373
I'm hitting a similar bug when trying to use -moz-element in an about: page
See http://crash-stats.mozilla.com/report/index/7de3b278-9342-4480-b567-2dab02100826
Markus, I hope you can fix this...
Assignee: nobody → mstange
blocking2.0: --- → final+
the problem seems to be here
http://mxr.mozilla.org/mozilla-central/source/layout/base/nsCSSRendering.cpp#3754
3754       nsContentUtils::NewURIWithDocumentCharset(getter_AddRefs(targetURI),

NewURIWithDocumentCharset is failing, and targetURI is null, but there is no null check nor return value check.
in my case it's trying to make aboutProtocolHandler build a new uri with spec "#elementID". If I check this for failure and tell the image is not ready, clearly it thinks there is no image and gives up (no crash but no image is shown)
see about:robots bug I added as blocking for the patch I was trying.
(Assignee)

Comment 6

8 years ago
Created attachment 470020 [details] [diff] [review]
protect against null uri

As Marco said, this doesn't fix the about:robots problem. Failing to generate the right URI for about:robots seems to be a separate bug.
Attachment #470020 - Flags: review?(roc)
(Reporter)

Comment 7

8 years ago
Maybe it should be an hash-element-ref rather than a URI, so it can work in data: URLs?
Comment on attachment 470020 [details] [diff] [review]
protect against null uri

Indeed, we should probably remove the URI dependency.
Attachment #470020 - Flags: review?(roc) → review+
Although really, the Web platform needs URIs to be fixed so that any URI can have a hash-ref.
(Assignee)

Updated

8 years ago
Keywords: checkin-needed
No longer blocks: 591104
(Reporter)

Updated

8 years ago
Blocks: 594645

Comment 10

8 years ago
http://hg.mozilla.org/mozilla-central/rev/70158f778f09
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Flags: in-testsuite+
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b7
Crash Signature: [@ nsURIHashKey::HashKey]
You need to log in before you can comment on or make changes to this bug.