Closed Bug 975223 Opened 6 years ago Closed 6 years ago

Add nsRefPtrHashtable method does Get+Remove without AddRef or Release

Categories

(Core :: XPCOM, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla30

People

(Reporter: mccr8, Assigned: mccr8)

References

Details

Attachments

(2 files)

I think I figured out what is causing the deadlock I was seeing in my patch in bug 96741.  nsSupportsHashtable has a method Remove that returns the data being removed, just with a swap, so there's no refcount on the data member.

In the first version of my patch, I changed it to a Get followed by a Remove, but this causes the value extracted from the hashtable to get an extra AddRef and Release of an nsJAR.  nsJAR has a weirdo Release() method that calls ReleaseZip() on its cache when it hits a refcount of 1, so if an object is being extracted that has a refcount of one, then it will hit a refcount of one twice, causing an extra ReleaseZip(), which I think causes a nested nsZipReaderCache::ReleaseZip(), which triggers the deadlock detector.

My solution is just to add a new method to nsRefPtrHashtable that does Get+Remove using a swap, so there's no extra ref count traffic.
Comment on attachment 8379769 [details] [diff] [review]
part 1 - Make braces less weird in nsRefPtrHashtable.

Review of attachment 8379769 [details] [diff] [review]:
-----------------------------------------------------------------

::: xpcom/glue/nsRefPtrHashtable.h
@@ +112,2 @@
>      if (aFound)
>        *aFound = true;

Might as well brace this while you're here.
Attachment #8379769 - Flags: review?(nfroyd) → review+
Attachment #8379770 - Flags: review?(nfroyd) → review+
https://hg.mozilla.org/mozilla-central/rev/775ed04f9f49
https://hg.mozilla.org/mozilla-central/rev/6f39cfbcb4c6
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
You need to log in before you can comment on or make changes to this bug.