Data store is declared with: NS_DECL_CYCLE_COLLECTION_CLASS_INHERITED(DataStore, DOMEventTargetHelper) But then the actual declaration of Traverse/Unlink is: NS_IMPL_CYCLE_COLLECTION(DataStore, mStore) ...so the CC isn't going to actually trace the wrapper cache. I'm not sure how bad this really is, because I think the wrapper will still be rooted in the GC, but I'm not entirely sure of what the consequences are, and it seems like this recently landed, so we should just backport it. Found while working on a patch for bug 1008348.

try run: https://tbpl.mozilla.org/?tree=Try&rev=6cabd1d69357

> because I think the wrapper will still be rooted in the GC But cycles through it won't be known to the cycle collector, then? Seems like this must be either a GC hazard or a leak...

Thanks Andrew for catching this! \^O^/

(In reply to Boris Zbarsky [:bz] from comment #2) > Seems like this must be either a GC hazard or a leak... Yes, it will certainly cause a leak in certain situations. Not telling the CC about something holding JS alive can cause the CC to unlink something that is actually alive. By itself, that will just cause null-derefs, but in concert with another error (where a class leaves dangling pointers after it is unlinked) that can cause sec-crits.

Andrew, I'm assuming that since this was found via audit that we don't have a test case or steps to reproduce, so I'm marking qe-verify-. Feel free to let me know if that changes or if you'd like us to do more here. Thank you.