Assignee: gagan → warren
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....
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.
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?
ok, I'll see what's up with the directory service.
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?
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?)
Please do. THanks.
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
You need to log in before you can comment on or make changes to this bug.