497013 - Crash [@ SinkContext::~SinkContext] with document.write in -moz-binding

Status: RESOLVED FIXED

(Core :: DOM: HTML Parser, defect)

Description

[Martijn Wargers (dead)]

Attachment: zipped up testcase

See zipped up testcase, which crashes Firefox 3 and current trunk build, when visiting the file named 'testcase.htm', wait a little while and then press the back button.

Breakpad report for trunk:
http://crash-stats.mozilla.com/report/index/ded73808-0a0f-412e-ac81-deadc2090608
0  	mozcrt19.dll  	arena_dalloc_small  	 obj-firefox/memory/jemalloc/crtsrc/jemalloc.c:4425
1 	mozcrt19.dll 	arena_dalloc 	obj-firefox/memory/jemalloc/crtsrc/jemalloc.c:4548
2 	mozcrt19.dll 	free 	obj-firefox/memory/jemalloc/crtsrc/jemalloc.c:6387
3 	xul.dll 	SinkContext::~SinkContext 	content/html/document/src/nsHTMLContentSink.cpp:649
4 	xul.dll 	HTMLContentSink::~HTMLContentSink 	content/html/document/src/nsHTMLContentSink.cpp:1569
5 	xul.dll 	HTMLContentSink::`scalar deleting destructor' 	
6 	xul.dll 	HTMLContentSink::Release 	content/html/document/src/nsHTMLContentSink.cpp:1596
7 	nspr4.dll 	nspr4.dll@0x858f 


Breakpad report for Firefox3.0.x:
http://crash-stats.mozilla.com/report/index/946e6a17-c797-4ec9-953d-b95de2090608?p=1
0  	xul.dll  	SinkContext::FlushTags  	 mozilla/content/html/document/src/nsHTMLContentSink.cpp:1341
1 	xul.dll 	HTMLContentSink::DidBuildModel 	mozilla/content/html/document/src/nsHTMLContentSink.cpp:1811
2 	xul.dll 	CNavDTD::DidBuildModel 	mozilla/parser/htmlparser/src/CNavDTD.cpp:466
3 	xul.dll 	nsParser::DidBuildModel 	mozilla/parser/htmlparser/src/nsParser.cpp:1006

Comment 1

[Daniel Veditz [:dveditz]]

In a debug build mSink looks like a deleted or corrupt object.

Comment 2

[Samuel Sidler (old account; do not CC)]

Who can own this?

Comment 3

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Fix

Comment 4

[Blake Kaplan (:mrbkap) (inactive)]

The reason this fixes this bug is because the call to mSink->OpenHead can flush tags, which runs XBL constructors. The XBL constructor in this case does a document.write, re-entering the parser. However, by that point, the parser thinks the head has already been pushed, so it tells the sink to close the head. But the sink hasn't yet opened the head anyway, so things get out of sync and badness ensues.

Comment 5

[Blake Kaplan (:mrbkap) (inactive)]

http://hg.mozilla.org/mozilla-central/rev/aa0ee4e7b713

Comment 6

[Martijn Wargers (dead)]

(In reply to comment #5)
> http://hg.mozilla.org/mozilla-central/rev/aa0ee4e7b713

By that line, you mean this bug is fixed?

Comment 7

[Blake Kaplan (:mrbkap) (inactive)]

Oops, yes.

Comment 8

[Daniel Veditz [:dveditz]]

Comment on attachment 390981 [details] [diff] [review]
Fix

Approved for 1.9.0.15, a=dveditz

Shouldn't this work for the 1.9.1 branch, too? If it does and you want to land it tonight then go ahead and do so. Add the approval request and I'll formally dot the i's after the fact tomorrow morning.

Comment 9

[Blake Kaplan (:mrbkap) (inactive)]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/cbe1f21a26c0

Checking in parser/htmlparser/src/CNavDTD.cpp;
/cvsroot/mozilla/parser/htmlparser/src/CNavDTD.cpp,v  <--  CNavDTD.cpp
new revision: 3.508; previous revision: 3.507
done

Comment 10

[Daniel Veditz [:dveditz]]

Comment on attachment 390981 [details] [diff] [review]
Fix

Approved for 1.9.1.4, a=dveditz

Comment 11

[Al Billings [:abillings - ex-MoCo]]

Verified fixed in 1.9.0 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.0.15pre) Gecko/2009092404 GranParadiso/3.0.15pre.

Verified fixed in 1.9.1 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090924 Shiretoko/3.5.4pre.