STEPS TO REPRODUCE 1. download cross-fuzz from: http://lcamtuf.coredump.cx/cross_fuzz/ 2. turn off popup blocking, turn off slow script warnings, turn off the pref "Open new windows in a new tab instead" 3. load file:///c:/moz/test/cross_fuzz/cross_fuzz_randomized_20110105_seed.html#567897 ACTUAL RESULT ###!!! ASSERTION: You can't dereference a NULL nsRefPtr with operator->().: 'mRawPtr != 0' Crash stack (see attachment for full stack): DOMSVGLengthList::IsAnimValList DOMSVGLengthList::GetNumberOfItems DOMSVGLengthList::GetLength NS_InvokeByIndex_P ... PLATFORMS AND BUILDS TESTED Bug occurs in a recent Fx trunk debug build (10.0a1) on WinXP (with wallpaper in bug 671484 applied) The source line is: 133: NS_ABORT_IF_FALSE(this == mAList->mBaseVal || this == mAList->mAnimVal, 134: "Calling IsAnimValList() too early?!"); where 'mAList' is null, 'this' appears to be valid.

It would be useful to have the full stack. I've still not been able to reproduce this.

Jonathan, I'm not sure what you mean by "full stack" - all stack frames are in the attachment if that's what you mean. Otherwise, please let me know what information you need and I'll try to reproduce it again. Which JS functions gives a DOMSVGLengthList as a result? Is it possible the crash happens when doing list.length on such a list after the corresponding content has been removed from the document? or if the document has no prescontext?

The root frame is a PL_DHashTableOperate call? Given that JS and the DOM are not thread safe, how can that be? If this is on the main thread I'd expect to see frames for spinning the event loop, for example. It should only be possible to create a DOMSVGLengthList implicitly, by accessing path.d.baseVal or path.d.animVal, both of which are of that type and are created lazily. The DOMSVGLengthList maintains a strong ref to its DOMSVGAnimatedLengthList (path.d), which in turn keeps a strong ref to its nsSVGPathElement. Whether the path element is in the tree, or whether it has a prescontext, shouldn't matter. Clearly there's a bug somewhere though.

(In reply to Jonathan Watt [:jwatt] from comment #3) > The root frame is a PL_DHashTableOperate call? There's more frames for sure, but that's all the debugger showed me (on Windows). > It should only be possible to create a DOMSVGLengthList implicitly, by > accessing path.d.baseVal or path.d.animVal, both of which are of that type > and are created lazily. The DOMSVGLengthList maintains a strong ref to its > DOMSVGAnimatedLengthList (path.d), which in turn keeps a strong ref to its > nsSVGPathElement. Whether the path element is in the tree, or whether it has > a prescontext, shouldn't matter. Clearly there's a bug somewhere though. OK, good to know. We could try to make some tests based on that...

I'm not really doing fuzzing anymore.

This doesn't assert for me on current trunk builds on either Win10 or Ubuntu 17.04. Funny enough, debug builds from a year ago were still asserting on this testcase, but with different ones than the bug was originally filed for.