User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:18.104.22.168) Gecko/2008070206 Firefox/3.0.1 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:22.214.171.124) Gecko/2008070206 Firefox/3.0.1 Ever since installing Firefox 3 release version (and after updating to 3.0.1), launch is unusually slow, 115 seconds from commencement to drawing of the initial untitled window. In addition, the Console.app log is filled with lines (takes up 10 pages when pasted into a word processor) like this: 2008-07-16 17:49:00.128 firefox-bin *** _NSAutoreleaseNoPool(): Object 0x11504b0 of class NSCFString autoreleased with no pool in place - just leaking In the place of "NSCFString" in other lines can be found "NSPathStore2" or "NSConcreteData" or "NSCFDictionary" or "NSIdEnumerator" and each of the hundreds of lines like this have a different offset, from 0x11504b0 to 0x11568f0 Reproducible: Always Steps to Reproduce: 1. launch Firefox 2. count time to drawing initial browser window (roughly same each time, 115 seconds) 3. check Macintosh Console.app log, same/similar entries exist Actual Results: 100% reproducible Expected Results: Should have launched expeditiously without these myriad leak errors powerpc-apple-darwin8.8.4
What version of OS X are you using? We can confirm then. Also, try running in safe mode, http://support.mozilla.com/en-US/kb/Safe+Mode.
Thanks. I am using OS X 10.4.11 1. I restarted Firefox in Safe Mode, problem disappeared. 2. Then I restarted Firefox with "All add-ons" set to off, again problem disappeared (except that the looong time to come to the initial browser window returned). I have a lot of extensions, so it will take me some time to do all the reboots required to isolate the misbehaving one, even longer if the problem is an interaction between two extensions.
Probably part of the issue is that you have many ad-ons. Try creating anew profile with none, and see what happens. http://support.mozilla.com/en-US/kb/Managing+profiles#Creating_a_profile
Could you put a list of the ad-ons you have up here? Thanks
For now, here is a list of active extensions (I use no themes): My active extensions are: Answers 2.2.48 DowloadHelper 3.1.1 FireFTP 1.0 Google Toolbar for Firefox 3.1.20080605M JSView 2.0.4 Neo Diggler 1.0.6 PDF Download 126.96.36.199 Stylish 0.5.7 Total Validator 5.3.0 URL LInk 2.02.2 I'll do the create new profile thing later (family stuff tonight:), but remember I already restarted Firefox (not in safe mode) with all add-ons disabled, wouldn't that be the same thing?
Following the instructions for "Creating a profile", i.e. entering /Applications/Firefox.app/Contents/MacOS/firefox -ProfileManager into the Terminal.app, does not work; for me it gets: -bash: Applications/Firefox.app/Contents/MacOS/firefox: No such file or directory Is the string given in the Creating a profile page somehow wrong? Perhaps it has changed for Firefox 3.x?
The profile page is up to date for FF3 (can someone confirm that). Having anew profile is the same as reinstalling FF, not just disabling ad-ons, like Safe-mode does. You say this is always reproducible when running normally, with ad-ons?
From my experience, the instructions in the profile page, though you may think they are up to date, simply don't work. I opened the FF 3 "package" contents to see if there was an executable of any kind with "ProfileManager" in the name, and there was not. And, yes, resetting FF 3 to boot normally with the exception of it having all extensions off does cure the problem (and turning the extensions back on invariably causes return of the problem); I have yet to go through the tedium of quitting and restarting, adding one extension at a time, since the bootup is so slow, and even then, as I've mentioned, there is the possibility of an interaction between two or more extensions. I seem to recall there is a debugger I can download that is based on analyzing the Gecko engine; would that be of any use here? And, I forgot to mention, I downloaded and ran the pre1 nightly build, same problem.
So, you are using build 2008072103? If having the extensions off makes the issue go away, that sounds terribly like an extension issue.
Yes, that build. I agree, but as near as I could tell from searching the database, this kind of problem isn't popping up on other platforms. Therefore, perhaps indirectly, there is a singular problem with the Mac version of FF 3, in combination with extensions. That I couldn't use the recommended command line to evoke the Profile Manager in some way suggests to me that changes to FF itself in the Mac version play a role here. What about that debugger? Of any use do you think? I have lots of hard drive space, but my processor is relatively slow.
I do not think that the debugger (which I have never head of) will work. This seems to be, if not a problem with the extension only (which seems most likely) an issue with Firefox, not Gecko. Gecko is the internal rendering engine, and I do not think Gecko will have that big of an impact on this issue. What are your system specs? How much RAM, how fast of a CPU, etc.
Sorry to have been away from this, more pressing commitments. What I need to explore this bug properly is the correct command line argument for creating a profile; see my note #6 in this thread indicating that the online instructions do not work, I need a proper string to do this by the book. Sometimes I feel as though Mac users are the skunks at the garden party. If someone has a correct command line to create a new profile properly, I'm prepared to continue to investigate this bug. BTW, system specs you requested: 733 mhz PowerPC processor with 1 MB (1:2) L2 cache, 1 MB L3 cache, 4 Altivec 'velocity processor' units (about same oomph as a 1.2 ghz Intel processor), 1 gig RAM. Altivec does not apply to Firefox per se, since FF not optimized for this, however much of the Tiger OS is optimized for these code accelerators, which should eliminate timing problems with the OS.
Updated to Firefox 3.0.2 release version. Looking at the bug-fix page for this release it says "Fixed Mac-specific issues: [blank line]" so, none were listed, no links. Whatever was done did not affect the leaking problem that initially prompted this bug report. Nor has the instruction page for creating a new profile via command line been changed to work with the Terminal program in OS X 10.4 Tiger. Therefore this bug ought not be closed until (a) the profile creation command line argument is corrected, and ultimately (b) the bug is fixed.
Title: THIS IS GETTING SERIOUS This is getting serious. Anyone can see from the above that I sincerely wanted to assist by testing properly, but the out-of-date instruction page for creating a new profile via command line has not been changed to work with the Terminal program in OS X 10.4 Tiger. By serious I mean that, since installing Firefox 3 and discovering this problem, I have lost 92.6 gigabytes of hard drive space on my boot drive. Sure I've added a few (and also deleted a few) applications and small data files, but absolutely not even 1 percent of 90 gigabytes. Now I have arrived at the point that my boot drive is 99% full, and I can't find, even with tools like OmniDiskSweeper, or various terminal commands, where all the disk space is being taken up. My suspicion is that, just as the new profile command line is non-standard to the OS X 10.4 Tiger OS, these massive memory leaks are generating an invisible log file somewhere that cannot be found by conventional means, at least not one that can be found with the tools normally designed to find such files. I also cannot believe I'm the only Mac user having this problem; typically people with newish Macs who try something like Firefox have huge hard drives and haven't run up against the disk full wall yet, since until that day arrives, everything works fine, except Firefox takes a couple of minutes to launch. This is unacceptable to Mac users who wish to use and support Firefox. As a matter of fact it is crucial for me, as, even if I stopped using Firefox, it is too late in the sense that my drive is almost full and I won't be able to use it much longer given the small amount of space I have left. I have some data from periodic occasions of using my Disk Utility log: On June 27, about a week before I first started using Firefox 3, my startup disk reported: Capacity 116.3 GB Used space: 23.3 GB Free space: 93.0 GB Now the last time I ran Disk Utility, October 17, it reported: Capacity: (still) 116.3 GB Used space: 116.0 GB Free space: 334.6 MB, that's right, megabytes, about a third of 1 gigabyte. Now, I admit there could be some mysterious other process happening, but I keep my Mac frequently maintained and instantly updated with security releases, the last one just a few days ago, so Ockham's Razor kind of common sense tells me the problem is likely with Firefox. Time to quit blaming the victim in your mind and give a genuine hand here.
Title: One Problem Solved, Others appeared Though I feel as though I'm typing to nobody here, I continue to attempt to solve this issue, or at least make some sense of it. Summary: -started with a re-installation of Firefox 3.03 -I cannot create an entirely new profile, because the instructions for doing so for Mac at http://support.mozilla.com/en-US/kb/Managing+profiles#Creating_a_profile simply do not work, see my previous report in this bug. -therefore, I work with Safe Mode: (1) the problem does indeed go away in Safe Mode. (2) if one chooses to "permanently disable add-ons" the problem also goes away when booting normally (other than Safe Mode), since extensions are disabled. I have been left with one excruciating alternative, taking hours: enabling one add-on/extension at a time, involving the very long bootup of the app (and it also takes significant time to fully quit). In addition, each time, I must run the Console application to see if the memory leaks have returned. By this method, I have determined the problematic extension: Google Toolbar 3.1.20080730M. Since reinstalling 3.0.3, I have encountered another problem I hadn't noticed before: one of two background calls are being made, not visible to the user, one to: -samo.nslb-15k.sj.mozilla.com on TCP port 443 (an https connection), or -static-fxfeeds.nslb-15k.sj.mozilla.com on TCP port 80 (an http connection). If I block either (or one, not sure) Firefox will not call a URL (no lights flash on my cable modem). My connection to the Internet is okay though, as I can open up the Add-ons window and check for updates and the request will go out over my cable modem (lights flash, report comes back "no updates found"). I do not believe these behind-the-scenes calls were being made before I reinstalled Firefox 3.0.3. I don't think users like to have external URLs called without their knowledge, so there needs to be an explanation of what these calls, originating in Firefox, are doing. This last bit may be unrelated to the present bug, a serendipity while testing. Should I start a new bug report, or is there a forum I could ask about/read about this? Please advise. Also, I happened to check the Error Console and found: Error: Warning: unrecognized command line flag -foreground Source File: file:///Applications/Firefox.app/Contents/MacOS/components/nsBrowserContentHandler.js Line: 706 Should this be reported as a bug? Please advise. Thanks everybody for all your help ;-)
Joe, if this issue is solved when the Google toolbar is disabled, it is a problem with the Google toobar and should be reported to Google. As for your other issue, please keep to one bug report per bug. So I will close this as INVALID, as it is not a bug in Firefox. Then report a new bug with your new issue.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.