40810 - QA|Bloat menu items don't work; Components.classes[progid] has no properties

Status: RESOLVED FIXED

(SeaMonkey :: General, defect, P3)

Description

[Matthew Cline]

Well, "Bloat: Clear Stats" works, but nothing else seems to.
"Dump New Stats" and "Dump All Stats" does nothing; dump memory leaks
gives rise to the error

JavaScript error:
chrome://navigator/content/navigator.js line 774: Components.classes[progid] has
no properties

Build 2000/05/26 on Linux 2.2.14, i686, RedHat 6.1

Comment 1

[Blake Ross]

confirming, I see the JS error on dump memory leaks. seems related to all the 
JS chrome "xxx has no properties" errors lately

Comment 2

[Asa Dotzler [:asa]]

Sorry for the spam.  New QA Contact for Browser General.  Thanks for your help
Joseph (good luck with the new job) and welcome aboard Doron Rosenberg

Comment 3

[Asa Dotzler [:asa]]

warren, are these items your's?  Is this a bug or does one have to preform some 
magic for these to work?  

Comment 4

[Warren Harris]

Work for me. Are you using a debug build?

Comment 5

[Matthew Cline]

It doesn't work with either a normal or a debug build.  I tried it again
with the 2000061611 build downloaded from mozilla.org.  "Dump New Stats"
and "Dump All Stats" simply takes me to a page that displays the HTML
code for a blank page.

The debug build was made from a CVS tree checked out on the 20000616
around 8PM Pacific time (although it claims that its build 20000614 on the
status bar).  When trying to do "Dump XYZ Stats", it gives this output:

###!!! ASSERTION: NS_ENSURE_TRUE(NS_SUCCEEDED(DoURILoad(aURI, aReferrer, aOwner,
 loadCmd, aWindowTarget, aPostData))) failed: '(!((DoURILoad(aURI, aReferrer, aO
wner, loadCmd, aWindowTarget, aPostData)) & 0x80000000))', file nsDocShell.cpp,
line 2409
###!!! Break: at file nsDocShell.cpp, line 2409
###!!! ASSERTION: NS_ENSURE_TRUE(NS_SUCCEEDED(InternalLoad(aURI, referrer, owner
, 0, 0, replace ? loadNormalReplace : (refresh ? loadRefresh : loadNormal)))) fa

For "Dump Memory Leaks", both debug and nondebug builds give the same error,
although the line of the error has changed to 845.

Comment 6

[Cyril Bortolato]

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

Comment 7

[Asa Dotzler [:asa]]

[e-mail] (Matthew Cline) are you still seeing this?

Comment 8

[Matthew Cline]

Using build 2000070408, loading "about:bloat" or "about:bloat?new"
just gives an "Error loading URL" message; trying to get the memory
leaks give me:

chrome://navigator/content/navigator.js line 865: Components.classes[progid] has
no properties

Comment 9

[Matthew Cline]

Using the debug build from the latest CVS tree, trying to load about:bloat
or about:bloat?new fails, just like the latest nightly build, but also
give me this message:

###!!! ASSERTION: NS_ENSURE_TRUE(NS_SUCCEEDED(DoURILoad(aURI, aReferrer, aOwner,
 loadCmd, aWindowTarget, aPostData))) failed: '(!((DoURILoad(aURI, aReferrer, aO
wner, loadCmd, aWindowTarget, aPostData)) & 0x80000000))', file
nsDocShell.cpp,line 2609
###!!! Break: at file nsDocShell.cpp, line 2609
###!!! ASSERTION: NS_ENSURE_TRUE(NS_SUCCEEDED(InternalLoad(aURI, referrer, owner
, 0, 0, loadType, loadInfoSHEntry))) failed: '(!((InternalLoad(aURI, referrer, o
wner, 0, 0, loadType, loadInfoSHEntry)) & 0x80000000))', file nsDocShell.cpp,
line 259
###!!! Break: at file nsDocShell.cpp, line 259

Which is pretty much the same message from the last debug build I tried,
but with different line numbers.

Comment 10

[Matthew Cline]

Alright, I figured out both of the problems.  For the non-memory
bloat menu items, it was that I wasn't defineing the environmental
variable XPCOM_MEM_BLOAT_LOG, so no bloat log file was getting
created.  In nsTraceRefcnt::DumpStatistics(), if both gBloatLog
and gBloatView are nsnull, then it silently returns a failure code.
I've supplied a patch that prints out an error message saying that
XPCOM_MEM_BLOAT_LOG must be defined; this will hopefully make people
look in the documentation (like I should have).

The only problem with this patch is that it prints the warning message
when Mozilla is being shut down, since I guess the bloat logger is
invoked then.

The other problem was that, when trying to dump memory problems,
that GC_LEAK_DETECTOR haden't been defined in the config-defs.h
for my debug build (and had presumeably not been defined for the
nightly builds).  Thus there was no leakdetector components, and
so when createInstance() in navigator.js tried to create an instance
of component://netscape/xpcom/leakdetector, it failed.  I've changed
createInstance() so that it will check to see that a given component
exists in Components.classes, and will give the name of the component
if it can't be found.  I also modified dumpMemoryLeaks() to give
a more informative error in case the leak detector object couldn't
be instantiated.  I'm also attaching this patch.

Comment 11

[Matthew Cline]

Attachment: Gives error message if nsTraceRefcnt::DumpStatistics() is called without env var XPCOM_MEM_BLOAT_LOG defined

Comment 12

[Matthew Cline]

Attachment: Gives more informative error messages if memory leak debugging isn't compiled into Mozilla

Comment 13

[Matthew Cline]

Assigning bug to myself, since I've supplied the patches.

Comment 14

[Asa Dotzler [:asa]]

re-assign.  thanks Matt.

Comment 15

[Blake Ross]

let me know if you need me to check in those patches once they're reviewed/approved

Comment 16

[Warren Harris]

Comments about your patches:

patch 1:
- You should printf to stdout instead of stderr. All the other messages go 
there. I tried to printf to stderr once, but messages would come out out of 
order.

- Why are you returning NS_OK instead of the error? This seems wrong. You should 
fix your js code to catch the error.

patch 2:
- What is this nsILeakDetector stuff? I don't see a 
component://netscape/xpcom/leakdetector anywhere in xpcom.

- Indentation screwed up.

Comment 17

[Matthew Cline]

The patches have been changed as per Warren's comments.

component://netscape/xpcom/leakdetector defined in
mozilla/xpcom/base/nsLeakDetector.cpp, and nsILeakDetector is defined
in mozilla/xpcom/base/nsILeakDetector.idl.  It's not compiled in
unless GC_LEAK_DETECTOR is defined in config-defs.h, and to do
that Mozilla has to be compiled with boehm GC enabled.  I tried
compiling it like that, but the resulting Mozilla dumped core.

Comment 18

[Matthew Cline]

Attachment: Corrected version of nsTraceRefcnt::DumpStatistic() patch

Comment 19

[Matthew Cline]

Attachment: Corrected version of memory leak debugging error messages patch

Comment 20

[Warren Harris]

Make it "fprintf(stdout, ..." like all the rest of the stuff in the file and 
you've got a deal. It will just make it easier to globally replace someday.

Comment 21

[Matthew Cline]

Alright, I changed my "printf(" to a "fprintf(stdout"; there was one
other use of a plain "printf(" in the file, so I changed that as well.

Comment 22

[Matthew Cline]

Attachment: Second corrected version of nsTraceRefcnt::DumpStatistic() patch, with printf() fixes

Comment 23

[Warren Harris]

Excellent. Check it in.

Comment 24

[Matthew Cline]

I don't have CVS checin privledges, someone else will have to do it
for me.

Comment 25

[Doron Rosenberg (IBM)]

warren, could you check this in?

Comment 26

[Warren Harris]

I checked in the nsTraceRefcnt stuff, but are you sure you want the dump thing 
in createInstance? That doesn't seem like it should go in a shipping product.

Comment 27

[Warren Harris]

No response on this. Closing.