If the final release of an nsProxyEventObject happens on a thread other than the thread being proxied to, the destructor for nsProxyEventObject will then get called on that other thread. The last thing the destructor does is NS_IF_RELEASE(mRoot), which releases the real, unproxied object. This can cause a threadsafety assertion in that object's implementation of Release, which won't necessarily be threadsafe.

This is not correct. The real raw object is held in the nsProxyEvent class. I made sure that releasing ALWAYS happens on the proper thread. Take a look at this release: http://lxr.mozilla.org/seamonkey/source/xpcom/proxy/src/nsProxyEvent.cpp#262 Let me know if this bug is not invalid.

I have to admit, I don't understand how nsProxyEventObject and nsProxyEvent interrelate, but I'm _seeing_ the assertion I described above with regularity in some code that I've written (but is not yet checked in). I can show it to you in gdb, if you like...

okay. I will drop by tomorrow.

moving to 0.9.1

dmose, please paste a stack of the assertion.

I haven't been seen this assertion for a while. Olga or Yulian, could you if see this or have anyway of coming up with a test case that can reproduce this, it would be very handy.

reassign to Olga as QA contact

Haven't seen this in months. Marking works for me.

I started seeing what I think is an instance of this again yesterday in my own patched tree. More details to come...

Moving out to Mozilla1.0, denominating nsenterprise.

*** This bug has been marked as a duplicate of 101252 ***