40997 - about:bloat fails DoURILoad()

Status: RESOLVED FIXED

(Core :: Networking, defect, P3)

Description

[rusty.lynch]

On at least my Linux build, none of the about:bloat?commands work. Attempting 
to load about:bloat results in the following assertions:

Entry at index 0 is about:bloat
###!!! ASSERTION: NS_ENSURE_TRUE(NS_SUCCEEDED(DoURILoad(aURI, aReferrer,
loadCmd, aWindowTarget, aPostData))) failed: '(!((DoURILoad(aURI, aReferrer,
loadCmd, aWindowTarget, aPostData)) & 0x80000000))', file nsDocShell.cpp, line
2380
###!!! Break: at file nsDocShell.cpp, line 2380
###!!! ASSERTION: NS_ENSURE_TRUE(NS_SUCCEEDED(InternalLoad(aURI, referrer, 0, 0,
replace ? loadNormalReplace : loadNormal))) failed: '(!((InternalLoad(aURI,
referrer, 0, 0, replace ? loadNormalReplace : loadNormal)) & 0x80000000))', file
nsDocShell.cpp, line 216
###!!! Break: at file nsDocShell.cpp, line 216
###!!! ASSERTION: NS_ENSURE_TRUE(NS_SUCCEEDED(LoadURI(uri, 0))) failed:
'(!((LoadURI(uri, 0)) & 0x80000000))', file nsDocShell.cpp, line 1076
###!!! Break: at file nsDocShell.cpp, line 1076
JavaScript error: 
 line 0: uncaught exception: [Exception... " 0x80004005 (NS_ERROR_FAILURE)
[nsIBrowserInstance.loadUrl]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)" 
location: "JS frame :: chrome://navigator/content/navigator.js :: BrowserLoadURL
:: line 1079"  data: no]


And, attempting to load about:bloat?clear results in a seemingly endless about
of:

###!!! ASSERTION: bad size recorded: 'aInstanceSize == 0 ||
entry->GetClassSize() == aInstanceSize', file nsTraceRefcnt.cpp, line 360

Comment 1

[Gagan]

->warren

Comment 2

[rusty.lynch]

ok, the problem had to do with the manner that we were creating our bloatlogs
directory. On unix, the new directory we were attempting to create ended up
being "/path/to/dist/bin/component.reg/bloatlogs", instead of 
"/path/to/dist/bin/components/bloatlogs".  Also, after the directory name
was fixed, the permissions on the new directory were wrong.

A patch follows....

Comment 3

[rusty.lynch]

Attachment: patch for nsAboutBloat.cpp

Comment 4

[rusty.lynch]

There is still a problem attempting to use about:bloat?clear.

The assertion in my first comment is a result of calling GetBloatEntry()
with a zero aInstanceSize from LogRelease() after the hash table
has been blown away.  Currently, GetBloatEntry() creates a new BloatEntry
if one doesn't exist.  So, after you blow away the hash, the next
LogRelease creates a new entry when LogRelease didn't mean too (I think.)

I can fix the behaviour by simply putting a check for aInstanceSize not 
set to zero before creating a new BloatEntry. Although, I'm still not sure
how usefull about:bloat?clear will be since most of the stats become
foobar.

For what it's worth the following patch allows for about:bloat?clear to work.

Comment 5

[rusty.lynch]

Attachment: patch for nsTraceRefcnt.cpp

Comment 6

[Warren Harris]

Hey Rusty,

I'm looking at your nsAboutBloat.cpp patch, and I think there must be something 
seriously wrong with the directory service. I think in all cases we should be 
looking for xpcom.currentProcess.componentDirectory, not just XP_UNIX. I bet the 
Windows version of this is giving the wrong thing (which is why I wrote 
xpcom.currentProcess.componentRegistry originally). Can you investigate that 
before committing this patch?

Comment 7

[rusty.lynch]

ok, I'll see what's up with the directory service.

Comment 8

[rusty.lynch]

It looks like dougt landed the nsIFile code in January that explicity
request the componentRegistry file path from the new directory service.
And then, in Feb some major changes for a handfull of bug fixes were made
to the nsDirectoryService implementation. (I suspect dougt's reason for
using componentRegistry instead of componentDirectory was fixed in the Feb
bug fixes.)

On my Win build, the same problem as described in the beginning of this bug
report exist.  Appling the patch does the trick just as on Linux.  I still
haven't proved this is also the case on a Mac box.  I crash my Mac build
by even attempting to go to about:bloat.  (But since I haven't successfully
been able to set the XPCOM env variables to turn on bloat logging, I don't
think I've proved anything.)

Does a Mac exit on asserts?  Maybe we should return a text stream containing
an error message instead of passing back the error code from nsAboutBloat's
NewChannel method?

Comment 9

[rusty.lynch]

Warren,

Using xpcom.currentProcess.componentDirectory ended up being the correct thing
to do on all platforms.  Can I go ahead an check in the code (but without the
#ifdef XP_UNIX?)  

Comment 10

[Warren Harris]

Please do. THanks.

Comment 11

[rusty.lynch]

The fix is checked into the build.  I still believe that about:bloat?clear
isn't doing the right thing, but that's a subject for another bug report.

Marking as fixed.