370702 - Fix refcount logging in cycle collecting auto refcount class

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Graydon Hoare :graydon]

The macros were set up wrong, producing some unusual leak reports. Fix them.

Comment 1

[Graydon Hoare :graydon]

Attachment: 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.

Comment 2

[Peter Van der Beken [:peterv]]

Can this be marked fixed now?

Comment 3

[Graydon Hoare :graydon]

Yes.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Actually not.  I've still been seeing wacky nsTraceRefcnt output.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: 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.)

Comment 6

[Peter Van der Beken [:peterv]]

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.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Second fix checked in to trunk.