Is this a new failure? I run the browser based tests where gc is performed after the each test completes and didn't see this in my 2-17 runs. Are you running the tests on WinXP really? I've been running on Win2k3, RHEL4 and Mac OS 10.4.4 but haven't on WinXP that recently.
My bad - During the JSGC_MARK_END GC callback, I called JS_RemoveRoot(), which messed up the garbage collector (sometimes).
Michael: how did removing a root after the mark phase completed mess up the GC, exactly? It would poke the GC, causing it to restart itself after the sweep phase completed, but that shouldn't be problematic. I hate a mystery. /be
This is extremely hard to debug. The JSXMLQName object was created during an XML parsing operation. During the sweep phase, the JSXMLQName affected would be freed, and restarting all of a sudden caused the JSObject that embedded the XML tree to mark its tree. I'll spend more time on the problem and comment later.
OK, I've found the problem. In xml_mark_tail(), if the XML is a list, this code marks the JSXMLQName: if (xml->xml_targetprop) js_MarkXMLQName(cx, xml->xml_targetprop, arg); Only if js_MarkXMLQName() is called from within this context, the JSXMLQName itself is never marked!
Created attachment 212530 [details] [diff] [review] Mark the QName itself during GC OK, here is the fix. This seems to be a very rare crasher. I could repro it reliably in my test suite, but it was impossible to narrow down.
This is the same problem described by the crashMe(false) testcase in bug 327691. Easier to split that case here (especially given the patch) than to track multiple problems in the same bug.
Created attachment 212676 [details] [diff] [review] fix The mark implementation for a GC-thing type should not have to call mark on the thing, only on its "children". What's really wrong is the lack of JS_MarkGCThing usage elsewhere. While here, I fixed another bug that Blake pointed out. Someone take this from my plate please! Too much food there already :-/. /be
Comment on attachment 212676 [details] [diff] [review] fix r=mrbkap
Comment on attachment 212676 [details] [diff] [review] fix This is branch-worthy, both for the next patch release and for Firefox 2. /be
Comment on attachment 212676 [details] [diff] [review] fix approved for 1.8.0 branch, a=dveditz for drivers
Fixed on branches. /be
verified fixed 184.108.40.206 win/linux/mac from today's build.
Verified fixed by BC six years ago.