about:bloat fails DoURILoad()

RESOLVED FIXED

Status

()

P3
normal
RESOLVED FIXED
19 years ago
16 years ago

People

(Reporter: rusty.lynch, Assigned: warrensomebody)

Tracking

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

19 years ago
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

19 years ago
->warren
Assignee: gagan → warren
(Reporter)

Comment 2

19 years ago
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....
(Reporter)

Comment 3

19 years ago
Created attachment 9385 [details] [diff] [review]
patch for nsAboutBloat.cpp
(Reporter)

Comment 4

19 years ago
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.

(Reporter)

Comment 5

19 years ago
Created attachment 9389 [details] [diff] [review]
patch for nsTraceRefcnt.cpp
(Assignee)

Comment 6

19 years ago
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?
(Reporter)

Comment 7

19 years ago
ok, I'll see what's up with the directory service.
(Reporter)

Comment 8

19 years ago
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?
(Reporter)

Comment 9

19 years ago
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?)  
(Reporter)

Updated

19 years ago
Blocks: 21730
(Assignee)

Comment 10

19 years ago
Please do. THanks.
(Reporter)

Comment 11

19 years ago
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.

Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED

Updated

16 years ago
QA Contact: tever → benc
You need to log in before you can comment on or make changes to this bug.