275221 - nsIDebug.idl, nsITraceRefcount.idl not frozen, but part of the SDK

Status: RESOLVED WORKSFORME

(Core :: XPCOM, defect)

Description

[Christian :Biesinger (don't email me, ping me on IRC)]

nsIDebug.idl and nsITraceRefcount.idl are part of the SDK, but not marked frozen.

since they are @status UNDER_REVIEW, maybe they should just be marked frozen?

Comment 1

[Darin Fisher]

Yes, these must be marked frozen.  Moreover, we have NS_GetDebug and
NS_GetTraceRefcnt that need to be marked frozen if they are not already marked
as such.  There may be a few other functions in nsXPCOMPrivate.h that need
similar loving.

Comment 2

[Benjamin Smedberg]

I believe we should definitely freeze nsIDebug the way it is. Is nsITraceRefCnt
debug-only? I'm a lot less certain about that one.

Comment 3

[Doug Turner (:dougt)]

i do not think nsITraceRefcount or nsIDebug.idl should be part of the SDK.  I
remember adding this as a private interface between the xpcom library and the
xpcom glue library -- something not intended for general use by developers.

Comment 4

[Benjamin Smedberg]

If the glue uses them, they need to be frozen, since changing them would break
old clients of the glue. We could do @status FROZEN + PRIVATE

Comment 5

[Darin Fisher]

Or, are these interfaces only needed in --enable-debug builds?  Can we make them
not be used when the glue is compiled with MOZILLA_STRICT_API?

Comment 6

[Doug Turner (:dougt)]

@status FROZEN + PRIVATE is fine with me...  something can be frozen and not put
into the public SDK.  

Darin is also right, these are only used in debug (or only should be used when
in a debug bug).  I do not see how MOZILLA_STRICT_API has anything to do with
this.  

Comment 7

[Darin Fisher]

> Darin is also right, these are only used in debug (or only should be used when
> in a debug bug).  I do not see how MOZILLA_STRICT_API has anything to do with
> this.  

Doug: effective a month or so ago, we now build the two versions of glue library
that are included in the SDK with MOZILLA_STRICT_API defined.  that was done so
that those glue libraries would use the frozen string API.  however, the glue
library that is linked into libxpcom_core (or libxul), is compiled against the
unfrozen internal string API.  this was also done so that external components
could be linked cleanly against libxpcom_glue.a + libxpcom.so.

So, this means that we could #ifdef the glue code to only use nsIDebug and
nsITraceRefcnt when MOZILLA_STRICT_API is not defined.  This seems like a good
idea to me because it is likely that users of the Gecko SDK may themselves
#define DEBUG for their own users.  If our headers see that and start using
nsIDebug or nsITraceRefcnt, then that could cause problems.

Make sense?

Comment 8

[Doug Turner (:dougt)]

so, i want to write a xpcom component using MOZILLA_STRICT_API.  during
development, i want to see if I am leaking and if so, do something about it. 
what you are proposing would have me disable MOZILLA_STRICT_API.  

Comment 9

[Darin Fisher]

Well, we could always have another #ifdef that selectively enables
nsITraceRefcnt and/or nsIDebug, but unless we are going to freeze those
interfaces, then it seems like they should not be used when MOZILLA_STRICT_API
is defined.

Comment 10

[Doug Turner (:dougt)]

Those interfaces are being used between the xpcom glue library and the xpcom
library -- not by the user.  The class, nsDebug and nsTrace(something), use them
internally.

Comment 11

[Darin Fisher]

> Those interfaces are being used between the xpcom glue library and the xpcom
> library -- not by the user.  The class, nsDebug and nsTrace(something), use 
> them internally.

Yes, but that does not change the fact that a consumer's binary (component or
exe) will have a dependency on those interfaces.  Therefore, we cannot change
those interfaces, and they are effectively frozen.  So, either we freeze them or
we make it so that by default consumers do not "use" them (by linking to a
static library that uses them or otherwise) when they say that they only want to
use frozen interfaces (i.e., when they define MOZILLA_STRICT_API).

Comment 12

[Doug Turner (:dougt)]

Darin -- my point is, they are frozen and they are not part of the SDK for
general use. MOZILLA_STRICT_API should not hide these two interfaces.

Comment 13

[Doug Turner (:dougt)]

mass reassigning to nobody.

Comment 14

[vb4guy]

Does anyone know if this interface was removed?  I am unable to make a reference to it from javascript although the article  https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIDebug it says that it is scriptable.

Comment 15

[Benjamin Smedberg]

Components.classes["@mozilla.org/xpcom/debug;1"].getService(Components.interfaces.nsIDebug) WFM in nightlies. And this bug, being about frozen interfaces, is no longer useful since we no longer have frozen interfaces.

Comment 16

[vb4guy]

Thanks, Benjamin.  I was hope that this interface allowed me to debug javascript but it only crashes Firefox.