nsWrappedJS has odd refcounting. When refcnt is 1, mJSObj isn't traced, but nsWrappedJS is just Released in XPCJSRuntime::FinalizeCallback assuming the mJSObj is about to be finalized. But if refcnt is increased back to > 1, nsWrappedJS is added to AddWrappedJSRoot and the next time tracing happens, mJSObj is traced the usual way. However if finalization happens before tracing, nsWrappedJS may end up having refcnt 2 during finalization and mJSObj will keep pointing to the now-finalized object. I've run the tests now 10+ times without problem TEST_PATH=dom/plugins/test make -C ff_build mochitest-chrome and initial results from https://tbpl.mozilla.org/?tree=Try&rev=a6a036903891 start to look good. The patch adds also a null check to GetJSObject since it in principle should have one (and used to have one until recently when khuey removed null-safe unmarkGray).

Not quite sure whether this bug needs to be security sensitive. I don't know how to trigger it from a web page given that it requires one to have weak ref to a wrappedJS, and web APIs don't have such things.

Perhaps the comment shouldn't be about unmarking gray, but "Make sure the JSObject is exposed to active JS."

Bill and Jon may find this interesting. A weird corner case of the interaction of browser root tracing and incremental GC.

Comment on attachment 808779 [details] [diff] [review] patch Review of attachment 808779 [details] [diff] [review]: ----------------------------------------------------------------- I guess this is really just implementing a write barrier (unmark gray during a GC triggers a write barrier I think). It makes me a little nervous about the other kinds of XPC roots we have, but I'd guess none of the rest have this weird weak reference lifetime stuff.

I'll mark this -other unless you think this could be a real problem.