See testcase, which crashes current trunk builds within 500ms. The xbl is encoded as a data url for convenience and only contains an <iframe>. This seems to have regressed between 2005-12-02 and 2005-12-03: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-12-02+04&maxdate=2005-12-03+07&cvsroot=%2Fcvsroot Regression from bug 315841, maybe? http://crash-stats.mozilla.com/report/index/1debbba1-5b46-11dc-94cf-001a4bd43ef6 0 @0x2662580 1 nsHTMLReflowState::InitAbsoluteConstraints(nsPresContext*, nsHTMLReflowState const*, int, int) mozilla/layout/generic/nsHTMLReflowState.cpp:1100 2 nsHTMLReflowState::InitConstraints(nsPresContext*, int, int, nsMargin const*, nsMargin const*) mozilla/layout/generic/nsHTMLReflowState.cpp:1803 3 nsHTMLReflowState::Init(nsPresContext*, int, int, nsMargin const*, nsMargin const*) mozilla/layout/generic/nsHTMLReflowState.cpp:315 4 nsHTMLReflowState::nsHTMLReflowState(nsPresContext*, nsHTMLReflowState const&, nsIFrame*, nsSize const&, int, int, int) mozilla/layout/generic/nsHTMLReflowState.cpp:180 5 nsAbsoluteContainingBlock::ReflowAbsoluteFrame(nsIFrame*, nsPresContext*, nsHTMLReflowState const&, int, int, nsIFrame*, unsigned int&, nsRect*) mozilla/layout/generic/nsAbsoluteContainingBlock.cpp:369 6 nsAbsoluteContainingBlock::Reflow(nsIFrame*, nsPresContext*, nsHTMLReflowState const&, int, int, int, int, nsRect*) mozilla/layout/generic/nsAbsoluteContainingBlock.cpp:159 7 nsBlockFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned int&) mozilla/layout/generic/nsBlockFrame.cpp:1138 8 nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, int, int, unsigned int, unsigned int&, nsOverflowContinuationTracker*) mozilla/layout/generic/nsContainerFrame.cpp:715 9 CanvasFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned int&) mozilla/layout/generic/nsHTMLFrame.cpp:577 10 nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, int, int, unsigned int, unsigned int&, nsOverflowContinuationTracker*) mozilla/layout/generic/nsContainerFrame.cpp:715 11 nsHTMLScrollFrame::ReflowScrolledFrame(ScrollReflowState const&, int, int, nsHTMLReflowMetrics*, int) mozilla/layout/generic/nsGfxScrollFrame.cpp:453 12 nsHTMLScrollFrame::ReflowContents(ScrollReflowState*, nsHTMLReflowMetrics const&) mozilla/layout/generic/nsGfxScrollFrame.cpp:535 13 nsHTMLScrollFrame::Reflow(nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned int&) mozilla/layout/generic/nsGfxScrollFrame.cpp:746 14 nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&, int, int, unsigned int, unsigned int&, nsOverflowContinuationTracker*) mozilla/layout/generic/nsContainerFrame.cpp:715 etc.

The first testcase used a windows media player plugin, this one uses the flash plugin, which crashes the same. http://crash-stats.mozilla.com/report/index/4f63115e-5b4a-11dc-97be-001a4bd43ef6

Recurring into frame construction messes up the frame tree... nsObjectLoadingContent::EnsureInstantiation() is the culprit.

This is basically what bug 90268 is about if I understand it correctly. Maybe we can wallpaper it for the time being by suppressing instantiation (and thus frame construction) in nsObjectLoadingContent during the LoadBindings() call from the frame constructor itself and then do EnsureInstantiation() off an event instead.

I swear we had this situation in another bug, though it wasn't bug 90268. At least I recall commenting about it... All I can find right now is bug 368183 and bug 228557, neither of which is quite it. Really, we should do the binding script stuff at a safer time, imo.

Boris: Bug 345711? It isn't a crash however.

Ah, indeed. That was it. I was only searching crashers, that's why I couldn't find it.

Comment on attachment 279760 [details] [diff] [review] wallpaper? >+ [noscript] void suppressInstantiation(in PRbool aSuppress); Seems like this should use the IDL boolean type, not PRbool (PRBool?). And maybe also be called setSuppressInstantiation, since the method name doesn't seem to match that it can be used to unsuppress.

Fixed by patch in bug 345711

Verified fixed, using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007102605 Minefield/3.0a9pre

Oops, I verified the bug with a build that didn't contain the fix for bug 345711 yet. I guess this was already worksforme before that, then.