Open Bug 1144352 Opened 5 years ago Updated 5 years ago

assert if a destructor attempts to extend object lifetime with AddRef()

Categories

(Core :: XPCOM, defect)

defect
Not set

Tracking

()

People

(Reporter: bkelly, Unassigned)

References

Details

Over in bug 1143223 I made a pretty stupid error where I AddRef'd my object from within its own destructor.  This was done by adding the object to an nsIThread for async callback on another thread.

It would be nice if we could assert this case somehow.  The easiest thing would be to just MOZ_ASSERT(mValue == 0) in ~nsAutoRefCnt, but that is hard due to stabilization.  Apparently we don't stabilize the ref count in all cases.

How else could we solve this?
NS_INLINE_DECL_THREADSAFE_REFCOUNTING doesn't use nsAutoRefCnt so we can still do what you're suggesting and account for stabilization, right?
(In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!) from comment #1)
> NS_INLINE_DECL_THREADSAFE_REFCOUNTING doesn't use nsAutoRefCnt so we can
> still do what you're suggesting and account for stabilization, right?

Well, I kind of wanted to do it for ThreadSafeAutoRefCnt as well.

Maybe we could add a ::Stabilize() method on the refcnt types that sets it to 1.  If thats called, then we MOZ_ASSERT(mValue == 1).  If its not called, then we MOZ_ASSERT(mValue == 0).
Yeah, that will probably work.  We can probably get away with adding a bool member to remember whether stabilization happened or not in debug mode.  Or, we may just be able to make different assumptions in the two cases, i.e., for nsAutoRefCnt, MOZ_ASSERT(mValue == 1), and for ThreadSafeAutoRefCnt, MOZ_ASSERT(mValue == 0), and add comments explaining where the 1/0 comes from.
You need to log in before you can comment on or make changes to this bug.