Closed
Bug 637286
Opened 13 years ago
Closed 13 years ago
Firefox4 freeze and is unusable when I try to open add-ons tab with Extensions pane selected
Categories
(Toolkit :: Add-ons Manager, defect)
Tracking
()
VERIFIED
FIXED
mozilla5
People
(Reporter: lylambda, Assigned: mwu)
References
Details
(Keywords: hang, Whiteboard: [mozmill-test-needed][mozmill-endurance])
Attachments
(7 files, 6 obsolete files)
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:2.0b13pre) Gecko/20110227 Firefox/4.0b13pre Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0b13pre) Gecko/20110227 Firefox/4.0b13pre Firefox4 freeze when I try to open add-ons's tab (visible here : http://uppix.net/7/d/9/da9282255ce693eb0fabf04f3b153.png). Then, the browser is unusable (no interactions) and I need to kill the process. Strangely, CPU didn't increase during the freeze. That's seems to depend about the number of add-ons, not about a specific one. This freeze happen exclusively when I installed more than 21 add-ons (compatibles). Less, the add-ons's tab can be open and all is okay. Just at 21 add-ons, the tab is hard to open (apparency incomplete) but no freeze. Reproducible: Always Steps to Reproduce: 1. Install more than 20 add-ons 2. Restart after install the last 3. Try to open add-ons's tab
Comment 1•13 years ago
|
||
Mozilla/5.0 (X11; Linux i686; rv:2.0b13pre) Gecko/20110227 Firefox/4.0b13pre Tried to reproduce issue but I was unable. Can you please try it again using a clean profile? And maybe try selecting other add-ons - just to make sure that it's not because of an add-on that FF freezes.
Updated•13 years ago
|
Component: General → Add-ons Manager
Product: Firefox → Toolkit
QA Contact: general → add-ons.manager
Version: unspecified → Trunk
Comment 2•13 years ago
|
||
Please list all of the addons you have installed. As best with URLs so we can quickly try to reproduce. Otherwise go to your profile, zip the extensions folder, and attach it to this bug. I highly suspect an add-on issue is the cause here.
Severity: major → critical
Keywords: hang
It's a big possibility but I can't see which did that. I will create a new profile as soon as possible. In my last test, I obtained a profile with which the bug happen not all time (first try, tab opens correctly, but the freeze happen all time during the second). It's better for install an add-on for create a list's extensions : [http://dl.free.fr/pmgOYIgB9] I can upload a zip folder's extensions if that can help. With this profile, enable or add one more extension give the systematic freeze (I try with "all-in-one sidebar 0.7.13rc1" and "Image Zoom 0.4.6").
PS : Select the little link "Télécharger ce fichier" for download the html list.
Updated•13 years ago
|
Comment 5•13 years ago
|
||
So I have tested with a new profile. When I put the extensions, the bug came back… I can't discover which does that. Maybe it's due to a combinaison of both or more ?
Comment 8•13 years ago
|
||
Same problem here with FF4 stable and a clean profile. In my case on Linux 64bits. I've tested several times with several clean profiles and different add-ons, but it hangs always. In my case, the limit is 31 extensions. By other side, the argument "...because of an add-on that FF freezes." isn't valid for me. IMHO, no add-on should be able to hang the manager add-ons. In Firefox < 4 this isn't occur.
Comment 9•13 years ago
|
||
(In reply to comment #8) > Same problem here with FF4 stable and a clean profile. In my case on Linux > 64bits. > I've tested several times with several clean profiles and different add-ons, > but it hangs always. In my case, the limit is 31 extensions. Are you saying that as soon as you have 31 add-ons it starts hanging, or something else?
Comment 10•13 years ago
|
||
(In reply to comment #9) > (In reply to comment #8) > > Same problem here with FF4 stable and a clean profile. In my case on Linux > > 64bits. > > I've tested several times with several clean profiles and different add-ons, > > but it hangs always. In my case, the limit is 31 extensions. > > Are you saying that as soon as you have 31 add-ons it starts hanging, or > something else? Well, now I'm doing more tests and the number is variable (~30) in function of the extensions. Perhaps is a problem of kb? with extensions folder >= 13880 KB it hangs.
Comment 11•13 years ago
|
||
(In reply to comment #10) > Well, now I'm doing more tests and the number is variable (~30) in function of > the extensions. Perhaps is a problem of kb? > with extensions folder >= 13880 KB it hangs. How long does it hang?
Comment 12•13 years ago
|
||
ive got the same prob on ubuntu maverick 64bit it seems a bit erratic to me, its both about how many addons but also about which addons. my extensions folder is 6.2mb and ive got 23 addons (not including the ones deemed not compatible such as prism and firefox notify) - and i badly need 5-10 more extensions to make it as useable as 3.6x some addons can be added without any problems, others cant, its about trying and failing (mostly failing) when it hangs it hangs forever(well ive only let it hang for about 10 mins at max), its not using any cpu at all, its just dead is there a way to go back to the old addons manager?
Comment 13•13 years ago
|
||
(In reply to comment #11) > (In reply to comment #10) > > Well, now I'm doing more tests and the number is variable (~30) in function of > > the extensions. Perhaps is a problem of kb? > > with extensions folder >= 13880 KB it hangs. > > How long does it hang? In my case, more than 30 minutes and so on... (In reply to comment #12) > is there a way to go back to the old addons manager? Same question.
Comment 14•13 years ago
|
||
If you enable extensions.logging.enabled and devtools.errorconsole.enabled and then restart, open the add-ons manager, wait for it to hang and then open tools - error console are there any messages listed?
Comment 15•13 years ago
|
||
(In reply to comment #14) > If you enable extensions.logging.enabled and devtools.errorconsole.enabled and > then restart, open the add-ons manager, wait for it to hang and then open tools > - error console are there any messages listed? I did this. The hang happened but the error console did not appear. Note that it hangs only if I am on the Extensions tab of the Add-on Mgr, or i switch to it. Is this what others are seeing too? Once it hangs the only way out that I know is to kill the process.
Comment 16•13 years ago
|
||
Comment 17•13 years ago
|
||
The attachment is compressed using XZ, use 7z on Windows to open/unpack it. I'm running the official Linux binary on Fedora 14 i686.
Comment 18•13 years ago
|
||
(In reply to comment #14) > If you enable extensions.logging.enabled and devtools.errorconsole.enabled and > then restart, open the add-ons manager, wait for it to hang and then open tools > - error console are there any messages listed? Error console also hangs as soon as you try to open Add-ons manager, so you cannot see anything in it. The only messages that I see logged in the usual Linux console are: $ firefox *** LOG addons.xpi: startup *** LOG addons.xpi: checkForChanges *** LOG addons.xpi: No changes found *** LOG addons.xpi: Opening database *** Blocklist::_loadBlocklistFromFile: blocklist is disabled (hang, no messages)
Comment 19•13 years ago
|
||
(In reply to comment #1) > Mozilla/5.0 (X11; Linux i686; rv:2.0b13pre) Gecko/20110227 Firefox/4.0b13pre > > Tried to reproduce issue but I was unable. Can you please try it again using a > clean profile? And maybe try selecting other add-ons - just to make sure that > it's not because of an add-on that FF freezes. Firefox _may_ or _may not_ hang with _the same set_ of extensions at different times. E.g. yesterday I could open add-ons manager, today it causes the browser to hang. In the meantime I've nothing except visiting new/old websites (i.e. I didn't install/uninstall/change any of my extensions).
Comment 20•13 years ago
|
||
Mozilla/5.0 (X11; Linux x86_64; rv:2.2a1pre) Gecko/20110327 Firefox/4.2a1pre SeaMonkey/2.2a1pre ID:20110327003001 SeaMonkey almost always hangs (usually, but not always, at extremely low CPU%) when I try to open the "Extensions" tab in about:addons (but it doesn't hang in Safe Mode). Once hung, the ps utility reports, in the WCHAN column for seamonkey-bin (and plugin-container if running) the label futex_wait_queue_me (the label may be truncated unless the WCHAN column is widened by e.g. "-o wchan:25" (without the quotes) on the ps command-line). The program still reacts to kill -15 but not to the keyboard or mouse. I have reproduced this problem a few minutes ago in this nightly. I have reported this problem (which also, but more rarely, happens in other circumstances) as bug 570316, to which my list of addons (from about:support) is attached. Duplicate?
Comment 21•13 years ago
|
||
(In reply to comment #20) > I have reported this problem (which > also, but more rarely, happens in other circumstances) as bug 570316, to which > my list of addons (from about:support) is attached. Duplicate? I doubt it, SeaMonkey and Firefox have quite different add-ons managers.
Comment 22•13 years ago
|
||
(In reply to comment #21) > (In reply to comment #20) > > I have reported this problem (which > > also, but more rarely, happens in other circumstances) as bug 570316, to which > > my list of addons (from about:support) is attached. Duplicate? > > I doubt it, SeaMonkey and Firefox have quite different add-ons managers. Your information is outdated since 2009. Until version 1.x inclusive, SeaMonkey could use extensions but it had no add-on manager to speak of. However, not mentioning alpha and beta builds, SeaMonkey 2.0 (built on 2009-10-27) and later uses the Toolkit addon manager, just like Firefox and Thunderbird, and the "new addon manager" affected SeaMonkey 2.1 and later exactly like it affected Firefox 4.0 and later.
Comment 23•13 years ago
|
||
I have this exactly this problem too. firefox hangs when i opening my addon manager. Version: firefox 4 OS: Fedora 14 please fix this bug :(
Comment 24•13 years ago
|
||
Same problem here with both offical firefox build and firefox-pgo (aur ) on Archlinux 64 bit i have experienced this problem especially with some addons , not at all. fireftp downthemall imacros all in one sidebar
Comment 25•13 years ago
|
||
Does this hang also happen when the Add-ons manager gets opened with another pane and then switched to Get Add-ons?
Comment 26•13 years ago
|
||
(In reply to comment #25) > Does this hang also happen when the Add-ons manager gets opened with another > pane and then switched to Get Add-ons? "Extensions", not "Get Add-ons". about:addons is one of the tabs of my multitab homepage, and it starts up, correctly, at whichever pane was used latest (usually "Available updates" or "Recent updates"). When I click "Extensions", I get the hang and need to kill the application.
Comment 29•13 years ago
|
||
That's in your case with SeaMonkey. I really would like to get feedback from users of Firefox. It's not clear yet by all the comments which pane is selected when the AOM gets opened and the hang appears.
Comment 30•13 years ago
|
||
In reply to comment #29 OK, well, Firefox users, please speak up. FTR, and in the light of comment #10, I have ATM 39 enabled addons plus a number of disabled ones. See bug 570316 attachment #499688 [details] for what they were on 2010-12-24.
Comment 31•13 years ago
|
||
(In reply to comment #29) > That's in your case with SeaMonkey. I really would like to get feedback from > users of Firefox. It's not clear yet by all the comments which pane is selected > when the AOM gets opened and the hang appears. For me it hangs when I try to see the list of installed extensions ("Extensions" on the left) - it never hangs on any other AOM's vertical tab. However like I've said scores of times, Firefox _may_ or _may not_ hang when I open OR switch to AOM's "Extensions". I haven't established a pattern, but I've found out that it depends on a day, like e.g. yesterday Firefox hung, today it works ;)
Comment 32•13 years ago
|
||
Ok, thanks. Lets get the summary updated to reflect the real issue. I will try later to get this hang reproduced on my box.
Summary: Firefox4 freeze and is unusable when I try to open add-ons tab → Firefox4 freeze and is unusable when I try to open add-ons tab with Extensions pane selected
Comment 33•13 years ago
|
||
seems it has something to do with memory usage. i just checked the mem tab in the system monitor and ff was using 350mb ram or so and launched the addons manager and it froze (yes only on the extensions tab) and had to kill ff , restart(all cache gone), 140mb used, extensions tab no problem oh and btw, its not just the extensions tab in the addons manager that causes this freeze, this addon that displays a list of the installed extensions from a toolbar button also causes the same freeze when clicked https://addons.mozilla.org/en-US/firefox/addon/extension-options-menu/ this is really a killer for me, tempted to go back to 3.6x until natty and hope this has been fixed by then. luckily i saved the ff3 profile seems to happen only on 64 bit linux tho?
Comment 34•13 years ago
|
||
(In reply to comment #33) > seems it has something to do with memory usage. i just checked the mem tab in > the system monitor and ff was using 350mb ram or so and launched the addons > manager and it froze (yes only on the extensions tab) and had to kill ff , > restart(all cache gone), 140mb used, extensions tab no problem Hardly related IMO. > > oh and btw, its not just the extensions tab in the addons manager that causes > this freeze, this addon that displays a list of the installed extensions from a > toolbar button also causes the same freeze when clicked > https://addons.mozilla.org/en-US/firefox/addon/extension-options-menu/ > > this is really a killer for me, tempted to go back to 3.6x until natty and hope > this has been fixed by then. luckily i saved the ff3 profile > > seems to happen only on 64 bit linux tho? 32 bit here, the same issue.
Comment 35•13 years ago
|
||
Can I just confirm that this is only happening on Linux? Is there anyone seeing this on Windows or OSX? What distro are you all using and are you using the Firefox downloaded from mozilla or one provided by your distro's package manager?
Comment 36•13 years ago
|
||
I am using Fedora 14. 32 bit. I downloaded Firefox 4 from mozilla website.
Comment 37•13 years ago
|
||
(In reply to comment #35) > Can I just confirm that this is only happening on Linux? Is there anyone seeing > this on Windows or OSX? > > What distro are you all using and are you using the Firefox downloaded from > mozilla or one provided by your distro's package manager? No ones wants to read the previous comments :) Fedora 14, i686 with all updates installed. Vanilla kernel 2.6.38.1. NVIDIA binary drivers 270.30. The official Firefox 4 binary from releases.mozilla.org Quite a lot of extensions. Absolutely random hangs/freezes depending on a time of day so it's practically impossible to establish if any of installed addons is to be blamed for this issue. A complete strace of firefox (with a hang) is attached earlier (comment #17).
Comment 38•13 years ago
|
||
i got it from the mozillateam stable ppa
Comment 39•13 years ago
|
||
(In reply to comment #35) > Can I just confirm that this is only happening on Linux? Is there anyone seeing > this on Windows or OSX? > > What distro are you all using and are you using the Firefox downloaded from > mozilla or one provided by your distro's package manager? Ubuntu 10.10 amd64 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0) Gecko/20100101 Firefox/4.0 - Opening Extensions pane of Add-on Manager causes browser to hang indefinitely. - This happens if more than N extensions are enabled (N seems to vary.) - This happens consistently...except on the few occasions when some yet to be discovered planets are perfectly aligned.
Comment 40•13 years ago
|
||
(In reply to comment #35) > What distro are you all using and are you using the Firefox downloaded from > mozilla or one provided by your distro's package manager? I got Firefox from: http://ppa.launchpad.net/mozillateam/firefox-stable/ubuntu (Ubuntu 10.10 amd64)
Comment 41•13 years ago
|
||
Comment 20 suggests that it doesn't hang when starting in safe mode, is the same true of Firefox? http://support.mozilla.com/en-US/kb/Safe%20Mode
Comment 42•13 years ago
|
||
(In reply to comment #41) > Comment 20 suggests that it doesn't hang when starting in safe mode, is the > same true of Firefox? > > http://support.mozilla.com/en-US/kb/Safe%20Mode I couldn't reproduce this problem in safe mode. But then I'm not sure if it doesn't trigger with just one extension installed.
Comment 43•13 years ago
|
||
(In reply to comment #41) > Comment 20 suggests that it doesn't hang when starting in safe mode, is the > same true of Firefox? > > http://support.mozilla.com/en-US/kb/Safe Mode That's correct. It does not hang in Safe Mode -- in fact, to keep it from hanging, I launch it in safe mode, disable a few extensions, then restart it. I've seen this w/ multiple profiles, and the no. of enabled extensions that apparently triggers this isn't always the same.
Comment 44•13 years ago
|
||
(In reply to comment #43) > (In reply to comment #41) > > Comment 20 suggests that it doesn't hang when starting in safe mode, is the > > same true of Firefox? > > > > http://support.mozilla.com/en-US/kb/Safe Mode > > That's correct. It does not hang in Safe Mode -- in fact, to keep it from > hanging, I launch it in safe mode, disable a few extensions, then restart it. Does that mean that it also doesn't hang in normal mode but with many of your extensions disabled? That is the hang only happens with a lot of extensions enabled at the same time?
Comment 45•13 years ago
|
||
(In reply to comment #44) > Does that mean that it also doesn't hang in normal mode but with many of your > extensions disabled? That is the hang only happens with a lot of extensions > enabled at the same time? Correct.
Comment 46•13 years ago
|
||
Not getting very far in reproducing this on my system as yet. It might be helpful for people that are seeing this to zip up their profile folder and email it to me directly
Comment 47•13 years ago
|
||
(In reply to comment #46) > Not getting very far in reproducing this on my system as yet. It might be > helpful for people that are seeing this to zip up their profile folder and > email it to me directly I've sent you my profile sans sensitive information. *Right now* when I try to invoke AOM, Firefox freezes. It *didn't* happen just three hours ago. :)
Comment 48•13 years ago
|
||
(In reply to comment #35) > Can I just confirm that this is only happening on Linux? Is there anyone seeing > this on Windows or OSX? > > What distro are you all using and are you using the Firefox downloaded from > mozilla or one provided by your distro's package manager? I'm on openSUSE Linux, currently 11.4, before that 11.3 and before that 11.2. I'm using SeaMonkey trunk builds downloaded from Mozilla. I reported the problem (as bug 570316, now duped to here) with a build datestamped 2010-05-10 (running on openSUSE Linux 11.2) but it may have happened earlier. I saw this on i386 (on a single-core machine) and I still see it on x86_64 (on a twin-core Pentium 4). Both machines had 2 GiB RAM. SeaMonkey is typically my most memory-hungry process, followed at some distance by Xorg, the rest are far behind. I haven't yet noticed anyone who had this bug except on Linux. I don't see this in Safe Mode. In December I saved my list of extensions from about:support, see comment #30 above. ATM I have some 39 extensions enabled, which seems to be enough to trigger the bug whenever I go to the addons manager's Extensions pane. Whenever this hang happens, I notice that the ps utility reports "futex_wait_queue_me" in the WCHAN column for seamonkey-bin. Dave, I'm willing to send you a .tar.bz2 of my profile, but it is a *SeaMonkey* profile, including browser data, mail messages, ChatZilla logs, etc., so please confirm if you are interested.
Comment 49•13 years ago
|
||
Here's is a gdb backtrace from my machine when firefox hangs.
Comment 50•13 years ago
|
||
(In reply to comment #49) > Created attachment 522696 [details] > Firefox's gdb backtrace when hanging. > > Here's is a gdb backtrace from my machine when firefox hangs. Awesome that gives us some good clues. Looks like we might be deadlocked in the zipreader cache after reading a localised description. Taras, I think you know some of this code, any ideas why we might be hitting this?
Comment 51•13 years ago
|
||
I'm looking at this. It might be related to mwu's omnijar work
Reporter | ||
Comment 52•13 years ago
|
||
(In reply to comment #46) > It might be helpful for people that are seeing this to zip up their profile > folder and email it to me directly Is it always necessary to send you some profile with the bug ? If yes, I can send one quickly.
Assignee | ||
Comment 53•13 years ago
|
||
Looks like a zip1->release -> zipcache->release -> zip2->release -> zipcache->release deadlock. Doesn't explain why it's linux only but at least we're getting somewhere. One interesting thing to try may be to set the pref extensions.alwaysUnpack to true. It may be related to the nested jar code. Setting this pref and reinstalling packed extensions will avoid using the nested jar code path.
Comment 54•13 years ago
|
||
(In reply to comment #52) > (In reply to comment #46) > > It might be helpful for people that are seeing this to zip up their profile > > folder and email it to me directly > > Is it always necessary to send you some profile with the bug ? If yes, I can > send one quickly. No in general we don't need it, but sometimes when we are having difficulty reproducing a problem it can help to be testing it out with exactly the same settings that you are using
Comment 55•13 years ago
|
||
(In reply to comment #53) > Looks like a zip1->release -> zipcache->release -> zip2->release -> > zipcache->release deadlock. Doesn't explain why it's linux only but at least > we're getting somewhere. > > One interesting thing to try may be to set the pref extensions.alwaysUnpack to > true. It may be related to the nested jar code. Setting this pref and > reinstalling packed extensions will avoid using the nested jar code path. Additionally, it would help to get some logs prior to setting mwu's pref. Please do something like export MOZ_JAR_LOG_DIR=/tmp/jarlog/ (trailing / is important) Then run firefox and get it into a deadlock state. This should give us a good idea of what jar is causing this.
Comment 56•13 years ago
|
||
looks like u ppl are getting somewhere. im not as technically advanced as you are but i set extensions.alwaysUnpack to true and that really made a difference. unfortunately a bad one.instead of firefox hanging my whole ubuntu maverick 64 hung and i found no other solution other than using the reset button. it was completely stuck i repeated this twice just to be sure
Comment 57•13 years ago
|
||
(In reply to comment #55) > Additionally, it would help to get some logs prior to setting mwu's pref. > > Please do something like > export MOZ_JAR_LOG_DIR=/tmp/jarlog/ > (trailing / is important) > Then run firefox and get it into a deadlock state. This should give us a good > idea of what jar is causing this. I just created a new profile and installed several add-ons. I launched firefox w/ MOZ_JAR_LOG_DIR set as you suggested. Attached are the jarlogs that were generated.
Updated•13 years ago
|
Attachment #522819 -
Attachment description: jar logs after hang → jar logs after hang (happened at the first launch after the add-ons were installed in a fresh profile.)
Comment 58•13 years ago
|
||
The problem is in zipreader cache code. We didn't catch it in our testing because one has to have >16 zips(extensions) to trigger it. Will get rid of the cache on trunk to get rid of this special case.
Assignee: nobody → tglek
Attachment #522821 -
Flags: review?(mwu)
Comment 59•13 years ago
|
||
(In reply to comment #58) > Created attachment 522821 [details] [diff] [review] > safest fix > > The problem is in zipreader cache code. We didn't catch it in our testing > because one has to have >16 zips(extensions) to trigger it. Will get rid of the > cache on trunk to get rid of this special case. Can you please drop a note here when the fixed trunk version is available?
Assignee | ||
Updated•13 years ago
|
Attachment #522821 -
Flags: review?(mwu) → review+
Comment 60•13 years ago
|
||
(In reply to comment #59) > > Can you please drop a note here when the fixed trunk version is available? https://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/tglek@mozilla.com-c4df5f3a4e89/ The 64bit build is ready now, 32bit is still building. Would be nice to get confirmation that this fixes the problem.
Updated•13 years ago
|
Keywords: checkin-needed
Comment 61•13 years ago
|
||
Not sure why this is only affecting Linux based on what we know at this point but I think we should be spinning out a fix in a .x release. Taras, is there a way we can automatically test this issue or is it too timing dependent?
blocking2.0: --- → ?
Comment 62•13 years ago
|
||
(In reply to comment #60) > https://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/tglek@mozilla.com-c4df5f3a4e89/ > > The 64bit build is ready now, 32bit is still building. Would be nice to get > confirmation that this fixes the problem. Did the following w/ the 64-bit build: - exploded the tar.bz2 in ~/temp/ - launched it w/ the same profile as the one in comment #57 using the following script: === #!/bin/bash cd /home/aslam/temp/firefox export MOZ_JAR_LOG_DIR=/tmp/jarlog-fix/ ./firefox -P tempProfile -no-remote & exit === If this is the correct way to test, then this build does _not_ fix the hang.
Comment 63•13 years ago
|
||
(In reply to comment #60) > (In reply to comment #59) > > > > Can you please drop a note here when the fixed trunk version is available? > > https://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/tglek@mozilla.com-c4df5f3a4e89/ > > The 64bit build is ready now, 32bit is still building. Would be nice to get > confirmation that this fixes the problem. I've tested it (on Ubuntu 10.04 64bits) and for me works. Although there are extensions that have been disabled because they do not recognize the version 4.0pre. To compensate for that were disabled, I installed some more and it still works correctly.
Comment 64•13 years ago
|
||
Well, there is still a problem. If after it restarts, after to install an extension, it is in "Get Add-ons" page and, while it load that page, I change to Extensions, it hangs.
Comment 65•13 years ago
|
||
unfortunately this new build behaved exactly like the regular ff4 on my ubuntu maverick 64. i added the exact same extensions that ff4 regular could handle before it would hang and, like on ff4 regular, it hangs on the extension tab if i add one more :(
Updated•13 years ago
|
Keywords: checkin-needed
Comment 66•13 years ago
|
||
Try both Tara's build, and rebuild Firefox 4 with Tara's patch, firefox still freeze for me. The work around to set the pref extensions.alwaysUnpack to true then reinstall add-ons seems to work ok. However, because of the randomness of the crash, I cannot be 100% sure.
Assignee | ||
Comment 67•13 years ago
|
||
I screwed up. Patch is getting built on try server - I'll post a link when they're ready.
Assignee: tglek → mwu
Attachment #522821 -
Attachment is obsolete: true
Attachment #523121 -
Flags: review?(tglek)
Assignee | ||
Comment 68•13 years ago
|
||
Forgot to check the returned pointer for null.
Attachment #523121 -
Attachment is obsolete: true
Attachment #523121 -
Flags: review?(tglek)
Attachment #523124 -
Flags: review?(tglek)
Assignee | ||
Comment 69•13 years ago
|
||
Builds with the last patch available at http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/mwu@mozilla.com-e47a81aa02d0/
Assignee | ||
Comment 70•13 years ago
|
||
Can't seem to write a test to cause this freeze.. the zip being released in ReleaseZip always seems to be the oldest one in the cache. Need to find a way to cause a mismatch.
Comment 71•13 years ago
|
||
(In reply to comment #69) > Builds with the last patch available at > http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/mwu@mozilla.com-e47a81aa02d0/ Tested the 64-bit build in the same way as before (see comment #62.) This time it did not hang -- repeated the test 3 times, all successful. Looks like this build fixed the problem. Thanks!
Comment 72•13 years ago
|
||
Mozilla/5.0 (X11; Linux x86_64; rv:2.2a1pre) Gecko/20110329 Firefox/4.2a1pre SeaMonkey/2.2a1pre ID:20110329225206 On this tinderbox-build I am able to select the Extensions pane, even take my time answering the "Add-on Compatibility reporter" menu for several extensions including ACR itself, and yet SeaMonkey doesn't hang, even (AFAIK) without the fix for this bug. Could this have been fixed by the fix for bug 627240 and/or by faking a version change (changing extensions.lastAppVersion in prefs.js while SeaMonkey was not running) after that fix had landed?
Comment 73•13 years ago
|
||
P.S. 42 addons enabled ATM, all in the profile now that bug 627240 has landed. (The only files still found in /usr/local/seamonkey/extensions/ are the *.xpi for the built-in themes and I'm using a 3rd-party one.)
Comment 74•13 years ago
|
||
yep this works. good work! 30ish extensions now, would crash around 22 before when will it land in a ppa? alternatively how do i brand it as firefox with ff icon etc?
Reporter | ||
Comment 75•13 years ago
|
||
Thanks Tony for this hard work !
Is it possible to change manually a file for obtain the fix ?
If not, I will waiting the bug's correction in a ppa. (in mozilla daily, stable ?)
>alternatively how do i brand it as firefox with ff icon etc?
For UbuntUser like you, use this one (but the fix didn't happen yet) :
sudo add-apt-repository ppa:mozillateam/firefox-stable
sudo apt-get update
sudo apt-get upgrade
Assignee | ||
Comment 76•13 years ago
|
||
Now with a working test for debug builds.
Attachment #523124 -
Attachment is obsolete: true
Attachment #523173 -
Attachment is obsolete: true
Attachment #523124 -
Flags: review?(tglek)
Attachment #523343 -
Flags: review?(tglek)
Comment 77•13 years ago
|
||
Comment on attachment 523343 [details] [diff] [review] Fix it harder, v3 I think the try/catch in testcase is redundant.
Attachment #523343 -
Flags: review?(tglek) → review+
Assignee | ||
Comment 78•13 years ago
|
||
Attachment #523343 -
Attachment is obsolete: true
Comment 79•13 years ago
|
||
pushed to mozilla-central http://hg.mozilla.org/mozilla-central/rev/4a0faa67237d
Assignee | ||
Updated•13 years ago
|
Status: NEW → RESOLVED
Closed: 13 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Comment 81•13 years ago
|
||
Please, when will it be available in the official PPA repository (ppa:mozillateam/firefox-stable)? Thanks.
Comment 82•13 years ago
|
||
(In reply to comment #81) > Please, when will it be available in the official PPA repository > (ppa:mozillateam/firefox-stable)? > Thanks. You'll have to speak to whoever maintains that repository, we don't control it.
Comment 83•13 years ago
|
||
Message has been sent to the maintainer of FF4-stable PPA in launchpad.net asking him to consider building new version.
Comment 84•13 years ago
|
||
(In reply to comment #82) > (In reply to comment #81) > > Please, when will it be available in the official PPA repository > > (ppa:mozillateam/firefox-stable)? > > Thanks. > > You'll have to speak to whoever maintains that repository, we don't control it. From where I can download this fixed version?
Comment 85•13 years ago
|
||
@Simon: see Comment 75, as soon as new build done.
Comment 86•13 years ago
|
||
(In reply to comment #85) > @Simon: see Comment 75, as soon as new build done. Thanks, but now I don't speak of unofficial PPAs. I ask for official mozilla releases. This bug is serious and it affects many more people than voted this bug. It would be important to release a corrected version soon. We are talking about a bug which prevents using Firefox 4 to many people.
Comment 87•13 years ago
|
||
A nightly that's to be released later today will include a fix for this bug ( http://forums.mozillazine.org/viewtopic.php?f=23&t=2151977 ) Mind that it's a _nightly_ so it can have major problems - some of them may even preclude a normal web browsing (like hangs, crashes, inability to use core browsing features, etc.)
Comment 88•13 years ago
|
||
(In reply to comment #87) > A nightly that's to be released later today will include a fix for this bug ( > http://forums.mozillazine.org/viewtopic.php?f=23&t=2151977 ) > > Mind that it's a _nightly_ so it can have major problems - some of them may > even preclude a normal web browsing (like hangs, crashes, inability to use core > browsing features, etc.) Thanks, but that thread is about Windows version. I use Linux.
Comment 89•13 years ago
|
||
(In reply to comment #87) > A nightly that's to be released later today will include a fix for this bug ( > http://forums.mozillazine.org/viewtopic.php?f=23&t=2151977 ) > > Mind that it's a _nightly_ so it can have major problems - some of them may > even preclude a normal web browsing (like hangs, crashes, inability to use core > browsing features, etc.) E.g. many people report that page scrolling leads to some unpleasant rendeiring artifacts, see bug 647315. The best way to have your Firefox 4.0 fixed, is to download its sources, apply this patch and compile Firefox (using -O2 -march=native -pipe CFLAGS/CXXFLAGS). It will take quite some time, but you will still have a stable Firefox release but without "extra" nightly brokenness. (In reply to comment #88) > > Thanks, but that thread is about Windows version. I use Linux. Don't pay attention to a mozillazine forum page title. It's historically called "Windows" but when a Windows build is ready it usually means that MacOS and Linux builds are also ready.
Comment 90•13 years ago
|
||
(In reply to comment #89) > (In reply to comment #87) > > A nightly that's to be released later today will include a fix for this bug ( > > http://forums.mozillazine.org/viewtopic.php?f=23&t=2151977 ) > > > > Mind that it's a _nightly_ so it can have major problems - some of them may > > even preclude a normal web browsing (like hangs, crashes, inability to use core > > browsing features, etc.) > > E.g. many people report that page scrolling leads to some unpleasant rendeiring > artifacts, see bug 647315. > > The best way to have your Firefox 4.0 fixed, is to download its sources, apply > this patch and compile Firefox (using -O2 -march=native -pipe CFLAGS/CXXFLAGS). > It will take quite some time, but you will still have a stable Firefox release > but without "extra" nightly brokenness. Ok, thanks. The patch is this: http://hg.mozilla.org/mozilla-central/raw-rev/4a0faa67237d, no? And the "stable" source of Firefox 4?
Comment 91•13 years ago
|
||
Download them here http://releases.mozilla.org/pub/mozilla.org/firefox/releases/4.0/source/
Comment 92•13 years ago
|
||
The trunk patch doesn't apply cleanly to Firefox 4.0 sources, here's a patch that works.
Comment 93•13 years ago
|
||
(In reply to comment #92) > Created attachment 523777 [details] [diff] [review] > Firefox 4.0 (branch) bug 637286 patch > > The trunk patch doesn't apply cleanly to Firefox 4.0 sources, here's a patch > that works. Thanks. One last question about compilation (it's an off-topic, sorry): how can I compile it in spanish?
Comment 94•13 years ago
|
||
(In reply to comment #93) > (In reply to comment #92) > > Created attachment 523777 [details] [diff] [review] > > Firefox 4.0 (branch) bug 637286 patch > > > > The trunk patch doesn't apply cleanly to Firefox 4.0 sources, here's a patch > > that works. > > Thanks. > One last question about compilation (it's an off-topic, sorry): how can I > compile it in spanish? You can always install Spanish support via XPI ( http://releases.mozilla.org/pub/mozilla.org/firefox/releases/4.0/linux-i686/xpi/ + setting general.useragent.locale in about:config ). Anyways, please, don't use bugzilla as a support forum, ask your questions (not related to this bug report) on http://forums.mozillazine.org/ or http://irc.mozilla.org/
Comment 95•13 years ago
|
||
Thanks for the help and for the patch. I've compiled Firefox 4 from sources (in spanish), optimized for my CPU and it works well with 38 extensions installed: 36 enabled and 2 disabled. :-)
Comment 96•13 years ago
|
||
Comment on attachment 523777 [details] [diff] [review] Firefox 4.0 (branch) bug 637286 patch Looking for approval to land this on the mozilla-2.0 branch to resolve this hang which affects users particularly on linux and with many extensions installed but taras tells me it is likely happening on windows too
Attachment #523777 -
Flags: approval2.0?
Comment 97•13 years ago
|
||
(In reply to comment #84) > (In reply to comment #82) > > (In reply to comment #81) > > > Please, when will it be available in the official PPA repository > > > (ppa:mozillateam/firefox-stable)? > > > Thanks. > > > > You'll have to speak to whoever maintains that repository, we don't control it. > > From where I can download this fixed version? This fixed version of Firefox 4.2a1pre should appear no more than 24 hours after comment #79, at http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ for Win32, Linux-i686 (32-bit), Linux-x86_64 and Mac (Universal binary for both 32- and 64-bit Intel machines). Use the appropriate *.installer.exe, *.tar.bz2 or *.dmg corresponding to your computer. This nightly is compiled from the "bleeding-edge" development sources, and at the moment it is considered a "pre-alpha" build. USE AT YOUR OWN RISK! This bugfix may or may not be retrofitted into earlier branches of the source tree. It isn't yet. If and when these "older but stabler" branches get the fix, the settings "status-2.0" (for Firefox 4.0), "status-1.9.2" (for Firefox 3.6.x) and/or "status-1.9.1" (for Firefox 3.5.x), near top right of this page, will change.
Comment 98•13 years ago
|
||
Are there any fixed and stable binary for Firefox 4.0 in mozilla repositories, not pre release ?
Comment 99•13 years ago
|
||
(In reply to comment #98) > Are there any fixed and stable binary for Firefox 4.0 in mozilla repositories, > not pre release ? No, we have to wait to get approval to land the patch on the stable branch and even then it will only be in branch nightlies until the next Firefox 4.0.x is released.
Comment 101•13 years ago
|
||
We should add this case to Litmus. let's get this into Tumucumaque Macaw.
Flags: in-litmus?
Updated•13 years ago
|
blocking2.0: ? → Macaw+
Assignee | ||
Comment 102•13 years ago
|
||
Comment on attachment 523777 [details] [diff] [review] Firefox 4.0 (branch) bug 637286 patch This patch is incomplete and doesn't contain the data used for the test. Going to verify the test works and post a new patch.
Attachment #523777 -
Attachment is obsolete: true
Attachment #523777 -
Flags: approval2.0?
Assignee | ||
Comment 103•13 years ago
|
||
Assignee | ||
Comment 104•13 years ago
|
||
http://hg.mozilla.org/releases/mozilla-2.0/rev/46171fccbeda
Comment 105•13 years ago
|
||
Newbie question: does "Status: RESOLVED FIXED" mean it will be fixed in an forthcoming patch? I landed here since I am experiencing this same issue. Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:2.0) Gecko/20100101 Firefox/4.0 ID:20110318052756
Comment 106•13 years ago
|
||
(In reply to comment #105) > Newbie question: does "Status: RESOLVED FIXED" mean it will be fixed in an > forthcoming patch? I landed here since I am experiencing this same issue. It will be fixed in Firefox 4.0.1
Comment 107•13 years ago
|
||
If you want a fixed version now, download and install Firefox from here: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-2.0/ This URL contains Firefox that will become version 4.0.1
Comment 108•13 years ago
|
||
Artem -- thanks!
Comment 109•13 years ago
|
||
Can everyone verify that this patch fixed the hang issue in Firefox 4.0.1 and the upcoming Firefox 5?
Target Milestone: --- → mozilla5
Reporter | ||
Comment 110•13 years ago
|
||
Yes, it is in 4.0.1. Thanks a lot, dev !
Comment 111•13 years ago
|
||
(In reply to comment #109) > Can everyone verify that this patch fixed the hang issue in Firefox 4.0.1 > and the upcoming Firefox 5? Yes, fixed in 4.0.1.
Comment 112•13 years ago
|
||
Thanks for your quick feedback. Marking this bug as verified fixed then.
Status: RESOLVED → VERIFIED
Comment 113•13 years ago
|
||
I think that would be a good candidate for our Mozmill endurance tests.
Whiteboard: [mozmill-test-needed][mozmill-endurance]
You need to log in
before you can comment on or make changes to this bug.
Description
•