See testcase, which crashes current trunk builds after a while. Normally, when you hit on the reload button after a while again, you get to see the crash. This seems to have regressed between 2007-10-19 and 2007-10-20: 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=2007-10-19+04&maxdate=2007-10-20+09&cvsroot=%2Fcvsroot Regression from bug 398135, somehow? Or from bug 345711? http://crash-stats.mozilla.com/report/index/2a224d6e-8105-11dc-a727-001a4bd43e5c 0 msvcr80.dll@0x153ea 1 nsAttrAndChildArray::RemoveChildAt(unsigned int) mozilla/content/base/src/nsAttrAndChildArray.cpp:218 2 nsGenericElement::cycleCollection::Unlink(void*) mozilla/content/base/src/nsGenericElement.cpp:3344 3 nsCycleCollector::CollectWhite(GCGraph&) mozilla/xpcom/base/nsCycleCollector.cpp:1478 4 nsCycleCollector::Collect(unsigned int) mozilla/xpcom/base/nsCycleCollector.cpp:2164 5 nsCycleCollector_collect() mozilla/xpcom/base/nsCycleCollector.cpp:2601 6 nsJSContext::Notify(nsITimer*) mozilla/dom/src/base/nsJSEnvironment.cpp:3194 7 nsTimerImpl::Fire() mozilla/xpcom/threads/nsTimerImpl.cpp:387 8 nsTimerEvent::Run() mozilla/xpcom/threads/nsTimerImpl.cpp:457 9 nsThread::ProcessNextEvent(int, int*) mozilla/xpcom/threads/nsThread.cpp:490 10 NS_ProcessNextEvent_P(nsIThread*, int) nsThreadUtils.cpp:227 11 nsBaseAppShell::Run() mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:154 12 nsAppStartup::Run() mozilla/toolkit/components/startup/src/nsAppStartup.cpp:170 13 XRE_main mozilla/toolkit/xre/nsAppRunner.cpp:3142 14 main mozilla/browser/app/nsBrowserApp.cpp:153 15 WinMain mozilla/browser/app/nsBrowserApp.cpp:166 16 __tmainCRTStartup crtexe.c:589 17 BaseProcessStart

If it still happens on trunk it's not bug 345711 since that was backed out.

Ah, doh, I guess it's a regression then from bug 398135, somehow.

This is great fun. Detaching the binding removes the fields, but removing fields executes them at the moment due to JS engine fun. So we end up executing the field while under UnbindFromTree, then crash when the parent's UnbindFromTree walks off the end of the child list (it's unbinding children, and one of the unbinds removes that child from the DOM!). This testcase might get fixed by bug 400705, but I think there are other ways to trigger script from UnbindFromTree (e.g. progress listeners on an iframe that blows away its docshell/loadgroup).

We need to fix scripts running from unbindfromtree. But that's a separate bug IMHO.

Ok, the testcase doesn't crash anymore, using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007102504 Minefield/3.0a9pre Can this bug be marked fixed?

Sure, if we get that separate bug filed....

First of all, does this happen still, with bug 400705. Second, is there a bug filed for getting a JS_HasOwnProperty or whatever was needed to do this right?

(In reply to comment #6) > Sure, if we get that separate bug filed.... Boris, what separate bug would that be? Jonas says we have bugs on JS_HasOwnProperty()...

> Boris, what separate bug would that be? "Shouldn't run scripts under UnbindFromTree".

So marking this fixed since the patch in bug 400705 fix this, right? I filed bug 402970 on the UnbindFromTree stuff

Yeah, bug 400705 fixed the testcase here.

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