Closed Bug 507628 Opened 10 years ago Closed 10 years ago

Infinite recursion crash with embed in binding

Categories

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

defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla1.9.3a1
Tracking Status
status1.9.2 --- beta2-fixed
blocking1.9.1 --- .8+
status1.9.1 --- .8-fixed

People

(Reporter: martijn.martijn, Unassigned)

References

Details

(4 keywords, Whiteboard: [sg:dos][fixed by 507991])

Attachments

(1 file)

361 bytes, application/xhtml+xml
Details
Attached file 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
If wanted, I can look for a regression range.
It doesn't seem to crash online, probably, because of bugzilla wackiness.
A regression range would be great, yes.
blocking1.9.1: --- → ?
status1.9.1: --- → ?
Flags: blocking1.9.2?
Flags: blocking1.9.2? → blocking1.9.2+
blocking1.9.1: ? → needed
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.
Gah.  All sorts of stuff in that range, including some jseng changes.  Bisect time, I guess...
Maybe Ria still has some hourly builds lying around from that time.
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?
Blocks: 491063
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().
Assignee: general → nobody
Component: JavaScript Engine → DOM
QA Contact: general → general
Oh, and I don't think this is security-sensitive, given that it's infinite recursion.
Summary: Crash [@ js_LookupPropertyWithFlags] embed in binding → Infinite recursion crash with embed in binding
This is the same issue as bug 507991. The patch in that bug fixes this.
Depends on: 507991
Ah, excellent.
Whiteboard: [fixed by 507991]
Ok, not blocking the release on this then.
Flags: blocking1.9.2+ → blocking1.9.2-
Flags: wanted1.9.2?
We should probably be setting the flags in bug 507991 where the actual patch resides.
blocking1.9.1: needed → ---
Whiteboard: [fixed by 507991] → [sg:dos][fixed by 507991]
Should be fixed by bug 507991.
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
blocking1.9.1: --- → .7+
Marking FIXED for 1.9.1.8, this was fixed by bug 507991.
Flags: wanted1.9.2? → wanted1.9.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
Keywords: verified1.9.1
OS: Windows XP → All
Hardware: x86 → All
Target Milestone: --- → mozilla1.9.3a1
Group: core-security
Landed crashtest
http://hg.mozilla.org/mozilla-central/rev/3054ada929a2
Flags: in-testsuite? → in-testsuite+
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.