507628 - Infinite recursion crash with embed in binding

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Martijn Wargers (dead)]

Attachment: testcase

Apparently, when looking at the stack, this is a javascript engine bug.
It also crashes 1.9.1. It doesn't seem to crash Firefox3.0.x.
It crashes with jit turned on and off.

http://crash-stats.mozilla.com/report/index/8320524e-0883-48bd-bca1-b57be2090731?p=1
0  	js3250.dll  	js_LookupPropertyWithFlags  	 js/src/jsobj.cpp:3775
1 	js3250.dll 	js_GetPropertyHelper 	js/src/jsobj.cpp:4254
2 	js3250.dll 	js_GetProperty 	js/src/jsobj.cpp:4339
3 	js3250.dll 	js_GetClassPrototype 	js/src/jsobj.cpp:5366
4 	js3250.dll 	js_ErrorToException 	js/src/jsexn.cpp:1183
5 	js3250.dll 	ReportError 	js/src/jscntxt.cpp:1253
6 	js3250.dll 	js_ReportErrorNumberVA 	js/src/jscntxt.cpp:1581
7 	js3250.dll 	JS_ReportErrorNumber 	js/src/jsapi.cpp:5620
8 	js3250.dll 	js_ReportOverRecursed 	js/src/jscntxt.cpp:1344
9 	js3250.dll 	js3250.dll@0xa5822 	
10 	js3250.dll 	js_Invoke 	js/src/jsinterp.cpp:1379
11 	xul.dll 	nsXPCWrappedJSClass::CallMethod 	js/src/xpconnect/src/xpcwrappedjsclass.cpp:1669
12 	xul.dll 	nsXPCWrappedJS::CallMethod 	js/src/xpconnect/src/xpcwrappedjs.cpp:570
13 	xul.dll 	PrepareAndDispatch 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:114
14 	xul.dll 	SharedStub 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:141
15 	xul.dll 	nsContentPolicy::CheckPolicy 	content/base/src/nsContentPolicy.cpp:157
16 	xul.dll 	xul.dll@0xa8ce37

Comment 1

[Martijn Wargers (dead)]

If wanted, I can look for a regression range.

Comment 2

[Martijn Wargers (dead)]

It doesn't seem to crash online, probably, because of bugzilla wackiness.

Comment 3

[Boris Zbarsky [:bzbarsky]]

A regression range would be great, yes.

Comment 4

[Martijn Wargers (dead)]

It seems to have regressed between 2009-05-19 and 2009-05-20:
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2009-05-19+04%3A00%3A00&enddate=2009-05-20+09%3A00%3A00

Bug 507991 has the same regression range, although that one seems unrelated to this one.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Gah.  All sorts of stuff in that range, including some jseng changes.  Bisect time, I guess...

Comment 6

[Martijn Wargers (dead)]

Maybe Ria still has some hourly builds lying around from that time.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Hmm.  So what I see locally seems to be an infinite recursion crash due to the fix for bug 491063.

The recursion I see is like so:

#6470 0x11f1847f in nsObjectLoadingContent::LoadObject (this=0x1e465b50, aURI=0x0, aNotify=1, aTypeHint=@0xbf8df60c, aForceLoad=0) at /Users/bzbarsky/mozilla/vanilla/mozilla/content/base/src/nsObjectLoadingContent.cpp:1165
#6471 0x12003063 in nsHTMLSharedObjectElement::StartObjectLoad (this=0x1e465b30, aNotify=1) at /Users/bzbarsky/mozilla/vanilla/mozilla/content/html/content/src/nsHTMLSharedObjectElement.cpp:429
#6472 0x120056a1 in nsHTMLSharedObjectElement::StartObjectLoad (this=0x1e465b30) at /Users/bzbarsky/mozilla/vanilla/mozilla/content/html/content/src/nsHTMLSharedObjectElement.cpp:133
#6473 0x12004b7c in nsRunnableMethod<nsHTMLSharedObjectElement, void>::Run (this=0x1e465dd0) at nsThreadUtils.h:264
#6474 0x11e8be54 in nsContentUtils::RemoveScriptBlocker () at /Users/bzbarsky/mozilla/vanilla/mozilla/content/base/src/nsContentUtils.cpp:4395
#6475 0x11bbf375 in nsAutoScriptBlocker::~nsAutoScriptBlocker (this=0xbf8df76b) at nsContentUtils.h:1565
#6476 0x11c296ed in PresShell::FlushPendingNotifications (this=0x1332a00, aType=Flush_Style) at /Users/bzbarsky/mozilla/vanilla/mozilla/layout/base/nsPresShell.cpp:4868
#6477 0x11eb3706 in nsDocument::FlushPendingNotifications (this=0x10f5000, aType=Flush_Style) at /Users/bzbarsky/mozilla/vanilla/mozilla/content/base/src/nsDocument.cpp:6305
#6478 0x11f165fb in nsObjectLoadingContent::NotifyStateChanged (this=0x1e465990, aOldType=nsObjectLoadingContent::eType_Loading, aOldState=2097152, aSync=1) at /Users/bzbarsky/mozilla/vanilla/mozilla/content/base/src/nsObjectLoadingContent.cpp:1519
#6479 0x11f1b7e6 in AutoNotifier::Notify (this=0xbf8dfa64) at /Users/bzbarsky/mozilla/vanilla/mozilla/content/base/src/nsObjectLoadingContent.cpp:231
#6480 0x11f1847f in nsObjectLoadingContent::LoadObject (this=0x1e465990, aURI=0x0, aNotify=1, aTypeHint=@0xbf8dfb8c, aForceLoad=0) at /Users/bzbarsky/mozilla/vanilla/mozilla/content/base/src/nsObjectLoadingContent.cpp:1165

I can't seem to get the crash stack this was originally reported with.  Did it really only have as much stack as comment 0 has?

Comment 8

[Boris Zbarsky [:bzbarsky]]

So what happens here is that we start loading the anonymous <embed>, with notifications enabled.  That makes us notify the state change from LoadObject; this notification includes the NS_EVENT_STATE_LOADING flag.  That lands us in nsCSSFrameConstructor::DoContentStateChanged, which posts a restyle event on the <embed>.

But the NotifyStateChanged call in this case had aSync = 1, so we immediately do a Flush_Frames flush right after the ContentStatesChanged notification.  But the <embed> is a block contained in an inline, so reframing it actually reframes the containing block, which in this case is the <div> with the binding on it.  And creating the new frame for the div creates a brand-new anonymous <embed> and binds it to the tree, which posts another runnable to do the load.

Then we unwind from the flush, and remove the script blocker, which synchronously runs said runnable and we recur into LoadObject().

Comment 9

[Boris Zbarsky [:bzbarsky]]

Oh, and I don't think this is security-sensitive, given that it's infinite recursion.

Comment 10

[Timothy Nikkel (:tnikkel)]

This is the same issue as bug 507991. The patch in that bug fixes this.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Ah, excellent.

Comment 12

[Johnny Stenback (:jst)]

Ok, not blocking the release on this then.

Comment 13

[Timothy Nikkel (:tnikkel)]

We should probably be setting the flags in bug 507991 where the actual patch resides.

Comment 14

[Timothy Nikkel (:tnikkel)]

Should be fixed by bug 507991.

Comment 15

[Johnny Stenback (:jst)]

Marking FIXED for 1.9.1.8, this was fixed by bug 507991.

Comment 16

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Verified fixed on 1.9.1 with builds on all platforms like Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8pre) Gecko/20100125 Shiretoko/3.5.8pre ID:20100125030736

Comment 17

[Timothy Nikkel (:tnikkel)]

Landed crashtest
http://hg.mozilla.org/mozilla-central/rev/3054ada929a2