Closed Bug 129959 Opened 23 years ago Closed 22 years ago

nsDebug depends on nsTraceRefcnt in debug builds.

Categories

(Core :: XPCOM, defect, P1)

All
Windows 2000
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: dougt, Assigned: dougt)

References

()

Details

(Keywords: embed, helpwanted, topembed-)

Attachments

(2 files)

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?
Severity: normal → major
Keywords: mozilla1.0, topembed
Priority: -- → P1
Hardware: PC → All
Target Milestone: --- → mozilla1.0
*** Bug 129958 has been marked as a duplicate of this bug. ***
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.
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.
are there alternatives, and can you explain how this is really useful?
> 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.
is it impossible to factor out and freeze an interface for stack walking?
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. :-(
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?
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?
Post mozilla 1.0 we can think about addressing a debuggable glue library.
Target Milestone: mozilla1.0 → mozilla1.0.1
embed triage: topembed-, not critical for immediate embedding needs but should be addressed to allow a debug option for embedders so adding embed keyword.
Keywords: topembedembed, topembed-
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
Keywords: helpwanted
Target Milestone: mozilla1.0.1 → mozilla1.2alpha
this is killing me...
Target Milestone: mozilla1.2alpha → ---
Uses a define XPCOM_GLUE to shield the glue library from including debugging features in xpcom.
Comment on attachment 73465 [details] [diff] [review] Wraps with FORCE_BUILD_REFCNT_LOGGING sr=shaver.
Attachment #73465 - Flags: superreview+
Comment on attachment 86695 [details] [diff] [review] Makes using the glue library possble in a debug build sr=shaver.
Attachment #86695 - Flags: superreview+
Comment on attachment 86695 [details] [diff] [review] Makes using the glue library possble in a debug build r=darin
Attachment #86695 - Flags: review+
Comment on attachment 73465 [details] [diff] [review] Wraps with FORCE_BUILD_REFCNT_LOGGING r=darin
Attachment #73465 - Flags: review+
landed the fix on the trunk last night.
Status: NEW → RESOLVED
Closed: 22 years ago
Keywords: mozilla1.0.1
Resolution: --- → FIXED
Please land this on the 1.0.1 branch. Once there, remove the "mozilla1.0.1+" keyword, and add the "fixed1.0.1".
Keywords: fixed1.0.1
Keywords: mozilla1.0.1+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: