988699 - CameraCommon.h re-#defines NS_LOG_ADDREF and NS_LOG_RELEASE for some reason

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Daniel Holbert [:dholbert]]

http://mxr.mozilla.org/mozilla-central/search?string=define%20NS_LOG_ADDREF shows that we have two definitions of NS_LOG_ADDREF right now (and similar for NS_LOG_RELEASE):
 - one canonical definition in nsISupportsImpl.h
 - another random one in dom/camera/CameraCommon.h

So, C++ code will have different behavior for this macro, depending on whether it happens to #include "CameraCommon.h" (directly or indirectly).

That seems undesirable.


These #defines were introduced in this cset for bug 779139:
 http://hg.mozilla.org/mozilla-central/rev/244bba751ce4#l3.137
which (per commit message and bug title) are mostly just about making camera objects participate in cycle collection, which I'd imagine shouldn't require any different special addref/release logging macros. 

mikeh, do you remember why we did this (and can these macros go away)?

Comment 1

[Mike Habicher [:mikeh] (high bugzilla latency)]

(In reply to Daniel Holbert [:dholbert] from comment #0)
> 
> mikeh, do you remember why we did this (and can these macros go away)?

At the time I had a script that would post-process the output to make nothing was leaking. I haven't used the macros since, so if they're causing problems, they can go away.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: fix

(In reply to Mike Habicher [:mikeh] from comment #1)
> I haven't used the macros since, so if they're causing
> problems, they can go away.

I'm not aware of them actively causing problems at the moment, other than confusion when someone searches for the definition of these macros. :)  (which is how I ran across this)

Anyway, it seems worth removing for that reason & from a code-hygiene perspective.

Patch attached, removing these macros and their inline helper-functions nsLogAddRefCamera/nsLogReleaseCamera (since the macros are the only clients of these functions).

Comment 3

[Mike Habicher [:mikeh] (high bugzilla latency)]

Comment on attachment 8398642 [details] [diff] [review]
fix

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

Make it so.

Comment 4

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/72c971501525

Comment 5

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/72c971501525

Comment 6

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

(In reply to Daniel Holbert [:dholbert] from comment #2)
> I'm not aware of them actively causing problems at the moment, other than
> confusion when someone searches for the definition of these macros. :) 
> (which is how I ran across this)

They'd certainly cause potential problems, in that they'd disable:
 * leak detection on tests run on tbpl
 * nsTraceRefcnt leak debugging tools
for all classes implemented in files that include CameraCommon.h.  Both are pretty serious.