Description of problem: Firefox sometimes hang on shutdown. This means that a new FF can not be started until the hanging process is terminated manually. Version-Release number of selected component (if applicable): firefox-24.2.0-1.el5_10 How reproducible: Sometimes, not always, didn't find out exactly what triggers the problem. Steps to Reproduce: 1. Start Firefox 2. Surf around with Firefox 3. Terminate with Quit or simply Ctrl+Q Actual results: The Firefox window disappears but a process /usr/lib64/firefox/firefox is still running. Expected results: Firefox should terminate itself. Additional info: This was discussed on the centos-devel list and confirmed to also exist with RHEL5. See the centos-devel archives http://lists.centos.org/pipermail/centos-devel/2013-December/009277.html and the CentOS bugtracker for some more infos.
I can confirm this with RHEL5. No plugins or extensions installed.
I can confirm I see this bug on RHEL5 (but not RHEL6). Like the original reporter, it doesn't always happen and I have no idea what triggers it. I haven't been able to trigger it by just opening Firefox and immediately close it, only after browsing for some time. However, after browsing for a few minutes it does trigger fairly consistently.
Support request filed: case #01002756.
As mentioned by the submitter of CentOS bug #6843 [1], visiting a site with active content [2] seems to trigger the issue. Also, it was noticed (through the support case) that the problem does not occur if firefox is run as root. [1] http://bugs.centos.org/view.php?id=6843 [2] http://www.techopedia.com/definition/4847/active-content
Can you please attach a backtrace of the frozen Firefox? (see http://fedoraproject.org/wiki/Debugging_guidelines_for_Mozilla_products#Application_freeze)
Martin, You'll find in the support case I opened (#01002756) that the problem can be easily reproduced at your end (and has been done so by the person handling the case). This way, you don't have to wait for customers to supply info required to resolve the issue.
And also, all requests for backtrace etc have been furnished in the support case.
Thanks Akemi, I'll therefore clear the needinfo flag.
Can you please test in safe mode? (without plugins). The backtrace looks like firefox is waiting for async plugin, launched by plugin-container. Can you also check which firefox child processes are running? (like plugin-container and so).
There is no "plugin" involved during firefox run or after the hang has occurred (ps examined). Also, the issue was tested in safe mode by other reporters. The current problem does not seem to be related to plugins.
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.
I don't understand the decision. The support case I opened (#01002756) is still being worked on. This is a bug that has to be addressed. What is the rationale for declining the request?
If root account works fine, it can be a permission problem. You can try to disable selinux (#setenforce 0). You may alse check logs (/var/log/messages and audit logs) if there's anything interesting. To move this bug forward, please tell the customer to perform those steps and post the result here. The available backtraces are unfortunately useless because does not shown the point of failure, but only waiting in socket kernel call. So, there are the steps here: 1) #debuginfo-install firefox 2) $firefox -g -d gdb 3) (gdb) r ...perform normal browsing, close the browser. If Firefox freezes in the end, interupt it by CTRL+C. But please note it here that firefox froze, no crashed. 4) print backtrace by "thread apply all bt full" and attach it here. Thanks!
hm, RHEL5 doesn't contain the debuginfo-install script. So please install it by "#yum install firefox-debuginfo"
I don't think it's an SELinux issue. I still experience the issue running in permissive mode and there are no related SELinux warnings.
(In reply to Martin Stransky from comment #18) > If root account works fine, it can be a permission problem. You can try to > disable selinux (#setenforce 0). You may alse check logs (/var/log/messages > and audit logs) if there's anything interesting. As noted by Ned Slider, disabling selinux does not make any difference. Nothing in /var/log/messages etc. > To move this bug forward, please tell the customer to perform those steps > and post the result here. The available backtraces are unfortunately useless > because does not shown the point of failure, but only waiting in socket > kernel call. > > So, there are the steps here: > > 1) #debuginfo-install firefox > 2) $firefox -g -d gdb > 3) (gdb) r > > ...perform normal browsing, close the browser. If Firefox freezes in the > end, interupt it by CTRL+C. But please note it here that firefox froze, no > crashed. > > 4) print backtrace by "thread apply all bt full" and attach it here. I have done the above. When I closed firefox, it exited normally. No process hanging. So, I did not get any backtrace. Program exited normally. (gdb) backtrace No stack. (gdb) quit
Here is what I found out: Note: because I don't have a RHEL 5.10 host to play with, my test host is running CentOS 5.10 with firefox-24.3.0-2.el5_10 and firefox-debuginfo-24.3.0-2.el5_10 from RHEL 5.10. I first tried to reproduce it running under gdb but, as Akemi alredy noted, I also didn't get it to hang, which is the first interesting thing. I've then tried to run firefox and close it, and it was hanging. Then I attached gdb to it did the "thread apply all bt full". That worked, and then while gdb was attached, I've sent firefox another SIGTERM and it terminated correctly. I hope it help to find the issue. I'll attach the trace.
Created attachment 860504 [details] GDB trace of hanging firefox
Created attachment 860519 [details] GDB trace of hanging firefox
Thanks for the traces. It's weird, I don't see any culprit there, looks like a regular FF close event when FF's waiting to threads to finish. I'd expect some crash in cairo_close or so.
As a Centos 5.10 user who has been affected by this bug for months now I have finally found a URL which reliably causes a hang on closedown. But, more interesting than that, a slightly edited URL causes the same page to be displayed but without the hang showing that it is not the page content which is causing the problem. Originally the URL which causes the hang had some parameters but removing them has the same effect. Type firefox http://www.brighton-hove.gov.uk/index.cfm close the browser window and the process hangs. Type firefox http://www.brighton-hove.gov.uk close the browser window and the process ends. I have tried the same on Centos 4.8 and they both close correctly.
Confirmed, I see the same behaviour described in comment 27 for the 2 URLs provided. Perhaps with a reliable replicator for the issue we might now see some progress?
I have narrowed the problem down to some HTML which defines stylesheets and displays a .JPG file. As before, it only happens if it is loaded after a HTTP 302 redirect. To recreate this unzip the attached html.zip in the root of your Apache webserver and access the page index.cfm (can be anything except index.html). e.g. 192.168.2.2/index.cfm which .htaccess redirects to 192.168.2.2/ and index.html is loaded.
Created attachment 913593 [details] HTML to place in Apache webserver root to recreate bug
Correction/Addition 1. The redirect in the .htaccess file should be Redirect 302 /index.cfm / and the URL obviously must be http://serveraddress/index.cfm 2. The default for Apache in httpd.conf is "AllowOverride Off" which must be changed to "AllowOverride All" for the DocumentRoot. Sorry ! It was very late when I edited my previous comments !
This issue seems to have resolved itself on the latest firefox update: # rpm -q firefox firefox-31.1.0-6.el5 I can no longer trigger the issue using the reproducer (http://www.brighton-hove.gov.uk/index.cfm) in comment #27
I spoke too soon - just had an instance where firefox failed to close and restart. hmm...
I can confirm that the problem has not been fixed in firefox-31.1.0-6.el5. The only difference I see is that, in the previous version I was always able to reproduce the issue just by visiting certain sites (e.g. www.java.com) but in the current version this is not the case. I had to load some pages (e.g. on http://www.brighton-hove.gov.uk) to make it happen.
additional test case on 5.11 1) start with a clean profile 2) change preferences: Portable Document Format(PDF) to "Always Ask" 3) go to: http://www.pdf995.com/samples/pdf.pdf (or your choice of pdf) 4) choose 'save as' -> boom stalled download 5) cancel is doing nothing 6) quit leaves firefox running (upon restart profile in use) 7) pkill firefox allows to use the profile again 8) undo 2) ie 'preview in browser' and hit the save button -> stall empty file 9) steps 6 and 7 again
Seems like the bug fix proposed for BZ #1150082 also fixes the shutdown problem: https://bugzilla.redhat.com/show_bug.cgi?id=1150082#c2 I visited the web site(s) that are known to cause the problem using the version of firefox that has the above patch applied. So far it never failed to shutdown cleanly.
Re comments #35, #36 and #37: As far as I can tell, all shutdown hangups of FF24 were some kind of futex f..., ahem, foulups. (And they were pretty close to being true "Heisenbugs" because any attempt to attack debugger/strace to the offending thread when it was in the hungup state made the problem go away.) Any problems observed with FF31 are likely to be unrelated. Problems described in BZ #1150082 are 100% unrelated because FF24 (or at least FF24 as included in RHEL5) does never call splice(2). The code is there but it is not called and when it needs to copy a file (or move it from one fs to another) it calls read(2) & write(2).
Ok, I stand corrected. Simon Matter's GDB trace shows a process stuck in splice(). Therefore it was probably the same problem but I am sure FF24 did not call splice() when it downloaded files.
@Pavel, you may be right with your statement that FF24 did not call splice() when it downloaded files - downloading files have worked fine and only started to be broken with FF31 (on EL5). The same goes for saving session data - it worked fine with FF24 and only started to be broken with FF31.
Bug 1150082 is going to be fixed in next release (Firefox-31.3.0) so please test when it's out. We're going to ship the patch for splice workaround here.
firefox-31.3.0-4 has just been released. I've done some quick testing. It looks as if this version does not show the problems reported not only in BZ #1150082 but also #1045340. This needs more extensive testing though.
Should be already fixed in firefox-31.4.0-1.el5_11. Please update the BZ if you see it again.