129959 - nsDebug depends on nsTraceRefcnt in debug builds.

Status: RESOLVED FIXED

(Core :: XPCOM, defect, P1)

Description

[Doug Turner (:dougt)]

I would like to remove this depend so that I can create a xpcom/glue library for
debuggin without requiring client to link to xpcom proper for the
nsTraceRefcnt::WalkTheStack symbol.  

Maybe if we can wrap this call with a FORCE_BUILD_REFCNT_LOGGING?

Comment 1

[Doug Turner (:dougt)]

Attachment: Wraps with FORCE_BUILD_REFCNT_LOGGING

Comment 2

[Matthias Versen [:Matti]]

*** Bug 129958 has been marked as a duplicate of this bug. ***

Comment 3

[timeless]

that's mean.

it means that i can't do setenv XPCOM_DEBUG_BREAK stack

if you're going to do this, please document it heavily.

Comment 4

[Doug Turner (:dougt)]

It depend on how things are built.  If you have a debug tree, maybe this is just
one of the standard build flags you use.

Comment 5

[timeless]

are there alternatives, and can you explain how this is really useful?

Comment 6

[Doug Turner (:dougt)]

> Are there alternatives:

Yes.  Remove nsDebug, nsISupportUtils, nsISupportImpl, and nsGenericModule
support from the glue library.  Not a nice thing to do.

> can you explain how this is really useful?

The glue library is a helper library for embedders.  It may only use frozen
API's to talk to xpcom proper.  nsTraceRefcnt class is not frozen and can not be
used by xpcom glue.

If we want to allow a debug option for embedders, this must be resolved.

Comment 7

[timeless]

is it impossible to factor out and freeze an interface for stack walking?

Comment 8

[Doug Turner (:dougt)]

Why?  This is *not* required for mozilla 1.0.  

I think that I am going have to make all trace ref counting be configurable with
a build option.  right not the stuff is enabled just by have DEBUG enabled.  :-(

Comment 9

[Doug Turner (:dougt)]

another thing I could just do is assert that a SDK build with DEBUG enabled is
not going to be available for the time being.  If you want that option, a
profile build is available.  thoughts?

Comment 10

[Alec Flett]

no, we're not freezing stack walking, debug-only code
This is reasonable, provided the mozilla build defaults still have the same
capability as the current build. It seems like you need to change some .mk files
so we don't loose this functionality in mozilla?

Comment 11

[Doug Turner (:dougt)]

Post mozilla 1.0 we can think about addressing a debuggable glue library.

Comment 12

[Kevin McCluskey (gone)]

embed triage: topembed-, not critical for immediate embedding needs but should
be addressed to allow a debug option for embedders so adding embed keyword.

Comment 13

[Doug Turner (:dougt)]

It would be nice to have a debug version of xpcom/strings which doesn't have
links to everything.  However, I do not see this happening in 1.01

Comment 14

[Doug Turner (:dougt)]

this is killing me...

Comment 15

[Doug Turner (:dougt)]

Attachment: Makes using the glue library possble in a debug build

Uses a define XPCOM_GLUE to shield the glue library from including debugging
features in xpcom.

Comment 16

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Comment on attachment 73465 [details] [diff] [review]
Wraps with FORCE_BUILD_REFCNT_LOGGING

sr=shaver.

Comment 17

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Comment on attachment 86695 [details] [diff] [review]
Makes using the glue library possble in a debug build

sr=shaver.

Comment 18

[Darin Fisher]

Comment on attachment 86695 [details] [diff] [review]
Makes using the glue library possble in a debug build

r=darin

Comment 19

[Darin Fisher]

Comment on attachment 73465 [details] [diff] [review]
Wraps with FORCE_BUILD_REFCNT_LOGGING

r=darin

Comment 20

[Doug Turner (:dougt)]

landed the fix on the trunk last night.

Comment 21

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

Please land this on the 1.0.1 branch.  Once there, remove the
"mozilla1.0.1+" keyword, and add the "fixed1.0.1".