Closed Bug 193585 Opened 22 years ago Closed 22 years ago

nsCOMPtr logging broken in GRE builds

Categories

(Core :: XPCOM, defect)

Product:
Core
Component:
XPCOM
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: dbaron, Assigned: dougt)

References

Details

Attachments

(1 file)

balance log from trunk build
52.85 KB, text/plain
Details
nsCOMPtr logging is broken in GRE builds. See http://mozilla.org/performance/leak-tutorial.html for documentation of nsCOMPtr logging (search for XPCOM_MEM_COMPTR_LOG). This makes debugging refcounting leaks very difficult. I've disabled the GRE in xpfe/bootstap/Makefile.in in my build as a workaround.
david - do you set MOZILLA_FIVE_HOME?
No, but I assume run-mozilla.sh does. In any case, the reason for the problem is pretty clear, I think -- XPCOM_GLUE defines out a bunch of the stuff this needs to work, and for some of the code in question (I think ~nsCOMPtr_base, but I'm not sure), we're picking up the version in the glue library.
david, this has been fixed. Ensure that MOZILLA_FIVE_HOME is set on linux. verified in today's trunk build on windows 2k and linux rh8.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
run-mozilla.sh has been setting MOZILLA_FIVE_HOME for ages. Did you even try testing this? The problem is that constructors are logged but destructors aren't, or the other way around, so that the tree gets all messed up.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
david i only verified that a log file was being created.
There isn't any special case nsCOMPtr code for XPCOM_GLUE. There may have been, but any has been removed: pwd /cygdrive/c/builds/trunk/mozilla/xpcom/glue bash-2.05b$ grep XPCOM_GLUE * Makefile.in: $(XPCOM_GLUE_SRC_LCSRCS) \ Makefile.in: $(XPCOM_GLUE_SRC_LEXPORTS) \ Makefile.in: rm -f $(XPCOM_GLUE_SRC_CSRCS:.cpp=.$(OBJ_SUFFIX)) nsDebug.cpp:#ifndef XPCOM_GLUE nsGenericFactory.cpp:#ifdef XPCOM_GLUE nsGenericFactory.cpp:#ifdef XPCOM_GLUE nsGenericFactory.cpp:#ifdef XPCOM_GLUE nsGenericFactory.cpp:#ifndef XPCOM_GLUE nsGenericFactory.cpp:#ifndef XPCOM_GLUE nsISupportsImpl.h:#ifdef XPCOM_GLUE nsISupportsImpl.h:#if defined(NS_DEBUG) && defined(NS_MT_SUPPORTED) && !defined(XPCOM_GLUE) nsMemory.cpp:#ifdef XPCOM_GLUE objs.mk:XPCOM_GLUE_SRC_LCSRCS = \ objs.mk:XPCOM_GLUE_SRC_LEXPORTS = \ objs.mk:XPCOM_GLUE_SRC_CSRCS := $(addprefix $(topsrcdir)/xpcom/glue/, $(XPCOM_GLUE_SRC_LCSRCS)) I think that you will notice only components that are built with XPCOM_GLUE enabled will not have nsTraceRefcnt logging - but this is totally okay since these components (ones built with XPCOM_GLUE) do not have access to things like nsTraceRefcnt -- they only have access to things that are frozen and part of our SDK (yes, this is by contract and nothing restricts them from reaching into xpcom and using this stuff, but I am not going to make it easy for them!). On windows 2k with a build from yesterday, I set XPCOM_MEM_LEAK_LOG and this is generated. Could you please tell me if this is enough verification? == BloatView: ALL (cumulative) LEAK STATISTICS |<----------------Class--------------->|<-----Bytes------>|<----------------Objects---------------->|<--------------References-------------->| Per-Inst Leaked Total Rem Mean StdDev Total Rem Mean StdDev 0 TOTAL 75 1308 52346 58 ( 295.12 +/- 341.79) 460214 11 ( 243.22 +/- 389.72) 67 XPCNativeScriptableShared 76 76 54 1 ( 10.45 +/- 5.36) 0 0 ( 0.00 +/- 0.00) 69 XPCWrappedNative 52 52 136 1 ( 68.25 +/- 39.19) 1728 1 ( 106.19 +/- 57.87) 99 nsBox 16 96 112 6 ( 57.47 +/- 31.59) 0 0 ( 0.00 +/- 0.00) 142 nsComponentManagerImpl 228 228 1 1 ( 1.00 +/- 0.00) 5461 1 ( 5.88 +/- 1.31) 204 nsGenericFactory 20 20 190 1 ( 95.25 +/- 54.78) 1535 1 ( 127.91 +/- 49.98) 213 nsHashtable 44 44 233 1 ( 112.70 +/- 64.46) 0 0 ( 0.00 +/- 0.00) 248 nsLocalFile 80 160 5390 2 ( 166.72 +/- 55.98) 32201 2 ( 170.35 +/- 54.96) 253 nsMemoryImpl 68 68 2 1 ( 1.33 +/- 0.58) 22 2 ( 4.93 +/- 1.26) 271 nsPluginDirServiceProvider 12 12 1 1 ( 1.00 +/- 0.00) 64 1 ( 2.46 +/- 0.55) 272 nsPluginHostImpl 100 100 1 1 ( 1.00 +/- 0.00) 17 1 ( 3.91 +/- 1.51) 329 nsSystemPrincipal 64 64 1 1 ( 1.00 +/- 0.00) 1399 0 ( 16.65 +/- 4.24) 345 nsVoidArray 8 312 2658 39 ( 688.91 +/- 270.22) 0 0 ( 0.00 +/- 0.00) 375 nsXPCComponents 48 48 4 1 ( 2.29 +/- 1.11) 44 1 ( 8.76 +/- 4.43) 389 nsXULPDGlobalObject 28 28 2 1 ( 1.33 +/- 0.58) 27 1 ( 3.94 +/- 1.46)
The issue is the nsTraceRefcnt code. And the log in comment 6 has nothing to do with nsCOMPtr logging.
This is a balance log for the nsComponentManagerImpl. dbaron, can you take a look at this log and tell me if anything looks broken? Also note that I truncated part of the log so that I didn't have to zip the log to post it to bugzilla.
david, could you let me know if you still see a problem with nsCOMPtr logging?
marking fixed.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
[06-21 21:51:57] <dwitte> when i run find-leakers, i get [06-21 21:52:29] <dwitte> er, i mean, when i run my build, it tells me one nsPrefBranch was leaked, -17 references from COMPtrs. [06-21 21:52:34] <dwitte> -17 sounds a bit odd. This is still a problem, and it's likely to remain a problem until someone actually fixes it.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(FWIW, I think the way to fix this is to make nsTraceRefcnt work the way nsMemory does -- with stubs that access a global retrieved from a function).
dwitte, what platform were you on? It is a known issue that our stackwalking code does not work correctly on windows 2k.
linux. this does remain a problem, as dbaron says.
(I think we should do the same thing for nsTraceRefcnt and nsDebug, so that they both work.)
Blocks: 205023
leaf was kind enough to move the file in cvs. Patch checked into trunk for 1.5b.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: