Fix refcount logging in cycle collecting auto refcount class

RESOLVED FIXED

Status

()

RESOLVED FIXED
12 years ago
12 years ago

People

(Reporter: graydon, Assigned: graydon)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Assignee)

Description

12 years ago
The macros were set up wrong, producing some unusual leak reports. Fix them.
(Assignee)

Comment 1

12 years ago
Created attachment 255420 [details] [diff] [review]
return 2 rather than 1 on stabilized incr

Actually I lied; the macros were fine as-is, we just need to return an appropriate refcount from incr operations, when in the stabilized-for-deletion state.
Attachment #255420 - Flags: review?(dbaron)
Can this be marked fixed now?
(Assignee)

Comment 3

12 years ago
Yes.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Actually not.  I've still been seeing wacky nsTraceRefcnt output.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Created attachment 257099 [details] [diff] [review]
patch 2

This makes the previous patch actually take effect -- we were ignoring the return values of incr and decr, but shouldn't be.  (This makes the Addref and Release methods look a little bit more like the threadsafe versions, for what it's worth.)
Attachment #257099 - Flags: review?(graydon)
Comment on attachment 257099 [details] [diff] [review]
patch 2

This fixes the nsTraceRefcnt output for me. Before it was reporting objects as leaking, even though they had balanced refcount trees.
Attachment #257099 - Flags: superreview+
(Assignee)

Updated

12 years ago
Attachment #257099 - Flags: review?(graydon) → review+
Second fix checked in to trunk.
Status: REOPENED → RESOLVED
Last Resolved: 12 years ago12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.