Confirmed on Linux. My stacktrace matches Jesse's, too. In this chunk of the stacktrace... > 7 libgklayout.dylib 0x130c3479 nsSVGPathGeometryFrame::NotifyRedrawUnsuspended() + 45 (nsSVGPathGeometryFrame.cpp:327) > 8 libgklayout.dylib 0x130a7181 nsSVGDisplayContainerFrame::NotifyRedrawUnsuspended() + 81 (nsSVGContainerFrame.cpp:253) > 9 libgklayout.dylib 0x130c0442 nsSVGOuterSVGFrame::UnsuspendRedraw() + 120 (nsSVGOuterSVGFrame.cpp:698) ... at stack level 9, the |SVGFrame| variable points to a frame that's filled with poison data. (lots of 0xf0dea7ff values) And this variable is used as the |this| pointer for stacklevel 8. So, from that point in the stacktrace downwards, we're already hosed. Note also that there's no SMIL-related methods in the stack trace. The crash happens while we're executing the 'removeAttribute("zoomAndPan");' line of javascript.

We in fact get hosed by this part of the stack to a frame destroy call:

Er, this stack: #14 0x12944aab in PresShell::FlushPendingNotifications (this=0x205d6fe0, aType=Flush_Style) at /Users/bzbarsky/mozilla/vanilla/mozilla/layout/base/nsPresShell.cpp:4778 #15 0x12bfbde8 in nsDocument::FlushPendingNotifications (this=0x14dac00, aType=Flush_Style) at /Users/bzbarsky/mozilla/vanilla/mozilla/content/base/src/nsDocument.cpp:6360 #16 0x12ac1b90 in nsComputedDOMStyle::GetPropertyCSSValue (this=0x1f08b030, aPropertyName=@0xbfffaa8c, aReturn=0xbfffaa4c) at /Users/bzbarsky/mozilla/vanilla/mozilla/layout/style/nsComputedDOMStyle.cpp:447 #17 0x12abe8c5 in nsComputedDOMStyle::GetPropertyValue (this=0x1f08b030, aPropertyName=@0xbfffaa8c, aReturn=@0xbfffabbc) at /Users/bzbarsky/mozilla/vanilla/mozilla/layout/style/nsComputedDOMStyle.cpp:310 #18 0x12abe1ec in nsComputedDOMStyle::GetPropertyValue (this=0x1f08b030, aPropID=eCSSProperty_font_size, aValue=@0xbfffabbc) at /Users/bzbarsky/mozilla/vanilla/mozilla/layout/style/nsComputedDOMStyle.cpp:255 #19 0x132934f7 in GetCSSComputedValue (aElem=0x205dcbe0, aPropID=eCSSProperty_font_size, aResult=@0xbfffabbc) at /Users/bzbarsky/mozilla/vanilla/mozilla/content/smil/nsSMILCSSProperty.cpp:71 #20 0x13293984 in nsSMILCSSProperty::GetBaseValue (this=0x205ea4b0) at /Users/bzbarsky/mozilla/vanilla/mozilla/content/smil/nsSMILCSSProperty.cpp:107 #21 0x13292a18 in nsSMILCompositor::ComposeAttribute (this=0x205eb37c) at /Users/bzbarsky/mozilla/vanilla/mozilla/content/smil/nsSMILCompositor.cpp:157 #22 0x1328d3d5 in DoComposeAttribute (aCompositor=0x205eb37c) at /Users/bzbarsky/mozilla/vanilla/mozilla/content/smil/nsSMILAnimationController.cpp:289 #23 0x1328dde5 in nsTHashtable<nsSMILCompositor>::s_EnumStub (table=0x205eb280, entry=0x205eb37c, number=0, arg=0xbfffae68) at nsTHashtable.h:420 #24 0x005326ec in PL_DHashTableEnumerate (table=0x205eb280, etor=0x1328ddc8 <nsTHashtable<nsSMILCompositor>::s_EnumStub(PLDHashTable*, PLDHashEntryHdr*, unsigned int, void*)>, arg=0xbfffae68) at pldhash.c:754 #25 0x1328e95f in nsTHashtable<nsSMILCompositor>::EnumerateEntries (this=0x205eb280, enumFunc=0x1328d3c4 <DoComposeAttribute(nsSMILCompositor*, void*)>, userArg=0x0) at nsTHashtable.h:241 #26 0x1328d304 in nsSMILAnimationController::DoSample (this=0x205dcd60, aSkipUnchangedContainers=0) at /Users/bzbarsky/mozilla/vanilla/mozilla/content/smil/nsSMILAnimationController.cpp:370 #27 0x13202b3e in nsSMILAnimationController::FlushResampleRequests (this=0x205dcd60) at nsSMILAnimationController.h:92 #28 0x131fe30e in nsSVGElement::FlushAnimations (this=0x205e4da0) at /Users/bzbarsky/mozilla/vanilla/mozilla/content/svg/content/src/nsSVGElement.cpp:1697 #29 0x131ff754 in nsSVGElement::GetAnimatedLengthValues (this=0x205e4da0, aFirst=0xbfffaffc) at /Users/bzbarsky/mozilla/vanilla/mozilla/content/svg/content/src/nsSVGElement.cpp:1207 #30 0x13268de1 in nsSVGRectElement::ConstructPath (this=0x205e4da0, aCtx=0xbfffb190) at /Users/bzbarsky/mozilla/vanilla/mozilla/content/svg/content/src/nsSVGRectElement.cpp:174 #31 0x131e173f in nsSVGPathGeometryFrame::GeneratePath (this=0x2116a600, aContext=0xbfffb190, aOverrideTransform=0x0) at /Users/bzbarsky/mozilla/vanilla/mozilla/layout/svg/base/src/nsSVGPathGeometryFrame.cpp:502 #32 0x131e1deb in nsSVGPathGeometryFrame::UpdateCoveredRegion (this=0x2116a600) at /Users/bzbarsky/mozilla/vanilla/mozilla/layout/svg/base/src/nsSVGPathGeometryFrame.cpp:254 #33 0x131df5ed in nsSVGOuterSVGFrame::UpdateAndInvalidateCoveredRegion (this=0x2116a330, aFrame=0x2116a600) at /Users/bzbarsky/mozilla/vanilla/mozilla/layout/svg/base/src/nsSVGOuterSVGFrame.cpp:647 #34 0x131ed3cd in nsSVGUtils::UpdateGraphic (aSVGFrame=0x2116a630) at /Users/bzbarsky/mozilla/vanilla/mozilla/layout/svg/base/src/nsSVGUtils.cpp:683 #35 0x131e1c19 in nsSVGPathGeometryFrame::NotifyRedrawUnsuspended (this=0x2116a600) at /Users/bzbarsky/mozilla/vanilla/mozilla/layout/svg/base/src/nsSVGPathGeometryFrame.cpp:335 In particular, in nsSVGOuterSVGFrame::UnsuspendRedraw we have this code: 697 for (nsIFrame* kid = mFrames.FirstChild(); kid; 698 kid = kid->GetNextSibling()) { 699 nsISVGChildFrame* SVGFrame = do_QueryFrame(kid); 700 if (SVGFrame) { 701 SVGFrame->NotifyRedrawUnsuspended(); 702 } and the call to NotifyRedrawUnsuspended() processes restyles and happens to destroy the frame that's currently pointed to by |kid|. Then we advance to a poisoned pointer, and from then on it's only a matter of time. It seems ... odd to me that this loop would trigger style flushes. If it's allowed to do that, we need to change how we iterate over the frames, use weakframes, etc. Or a scriptblocker to prevent them. Or something.

We need to push the FlushAnimations calls out of GetAnimatedLengthValues etc up to ... somewhere else. Maybe move them into FlushPendingNotifications itself?

We also need to hook up SMIL animation to for-animation restyles (bug 537139) and possibly also to nsRefreshDriver. Might that make this a moot point?

dholbert, you're fixing this right?

Yeah -- based on comment 5, I think bug 547333's followup should fix this.

This crashed in yesterday's nightly... 20100302030752 ba77049941c3 and doesn't crash in today's nightly: 20100303031122 d50a6e09b8d0 pushlog is http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ba77049941c3&tochange=d50a6e09b8d0 --> Comment 8 is correct; this is fixed by bug 547333's followup