Description of problem: Since few weeks, help desk team are getting big number of complains about Firefox crashes. Mostly random, but majority of affecting people is using salesforce.com. Version-Release number of selected component (if applicable): firefox-1.5.0.12-7.el5 How reproducible: Random, let's end user to use firefox for a day, he will get few crashes. Steps to Reproduce: Not really 100% reproducible.
Need to add that most of the time it happens when submitting stuff to Sales Force (heavy need of JavaScript), and it did not happen with previous release (1.5.0.12-7).
Another correction, version which is failing is firefox-1.5.0.12-9.el5
Marek, I need your help, either go with the following procedure for getting useful backtraces, or at least give us exact version of the package this crash happens? Is it firefox-1.5.0.12-9.el5 all the time? Which architecture? I need to know which exact package is causing this problem, otherwise I am not able to get any useful information from the core dumps. The standard blurb about -debuginfo follows: Please install firefox-debuginfo; in order to do this you have to enable -debuginfo repository. yum install --enablerepo=\*debuginfo firefox-debuginfo (if you use x86_64 firefox, install firefox-debuginfo.x86_64 package). Then run firefox with a parameter -g. That will start firefox running inside of gdb debugger. Then use command run and do whatever you did to make firefox crash. When it happens, you should go back to the gdb and run (gdb) thread apply all backtrace This produces usually many screens of the text. Copy all of them into a text editor and attach the file to the bug as an uncompressed attachment. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
I have the above strace log, will that help or you still want me to run the gdb
The strace is useless in case of SIGSEGV, my core dump are from firefox-1.5.0.12-7.el5 as I mentioned in my first comment, in second one, I've attached list of all packages (gtk..). I was not able to get a backtrace as the user is quite busy and doesn't want to troubleshoot it with me via vnc.
Created attachment 294660 [details] list of all installed packages
Here is what i got from the user whose firefox was crashing everytime he tried to open gtk-file-selector (save as, browse, print, etc.) I hope it helps. Let me know if you need anything else.
What else do you need for debugging?
Obtained gdb backtrace from other core dump files core.3798, core.3896, core.4046 It is a little different from other backtraces which were attached earlier. Thought it will be usefull.
Firefox just crashed again. Here's what I have installed: nss-3.11.7-1.3.el5 nspr-4.6.5-3.el5 firefox-1.5.0.12-11.el5_1 Should I be running the updated nss nspr from above if I want to help test this fix?
Help Desk has been deploying the latest brew packages (http://brewweb.devel.redhat.com/brew/buildinfo?buildID=69239), and we have had a lot of success. We are still not 100% rid of our crashes, but we are back to a stability level that we had prior to 5.1 rolling out and all hell breaking loose!
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2008-0147.html
*** Bug 432967 has been marked as a duplicate of this bug. ***
*** Bug 432973 has been marked as a duplicate of this bug. ***
*** Bug 434816 has been marked as a duplicate of this bug. ***
firefox still crashes on me at least once daily with the latest build. Is there another bz tracking the latest crashes?
Sorry if this sounds dumb, but https://rhn.redhat.com/errata/RHBA-2008-0147.html says (in part): ..packages were linked against an incorrect version of a library which would cause Firefox to randomly crash while the browser was in use. but looking at the new srpm I can't see any change to the libraries that the specfile specifies. Would it be possible to explain which libraries were incorrectly being picked up and perhaps what was changed to correct it? Something in the brewbuilder setup perhaps?
It's looking to us more and more like we have multiple issues here. My question to those still experiencing crashes with the latest firefox 1.5: If you remove all of your plugins do you still see instability? We are pointing our fingers at flash currently, but I don't have enough info yet to say that it is definitely causing most of the issues that we are seeing.
Is there a possibility of a fix for this or will a newer release of FireFox be offered in yum updates or the RHN Channel. It is very difficult to run my workstation at work running a RHEL5.1 Server as my primary machine with the browser crashing constantly. Any updates or status would be greatly appreciated. thanks
I removed all of my plugins and still get crashes. I don't believe flash was involved in my last crash. I believe most, if not all of the crashes occur when opening a dialog box that opens and external file, such as a pdf file. Once the crash occurs, if I return to the same site and open the file, the file opens fine.
I agree when you try to open a dialog box, for example when I was on RHN Network trying to upload a sosreport the browser crashes. I have to use Konqueror now, which does not have the functionality as FireFox has built in.
(In reply to comment #39) > firefox still crashes on me at least once daily with the latest build. Is there > another bz tracking the latest crashes? Yes, new crashes are tracked at bug 433823
Hi All. If this is related to the bug in Bug 430140 you might want to see the thread at: http://www.centos.org/modules/newbb/viewtopic.php?topic_id=11589&viewmode=flat&order=ASC&start=20 It seems to be mainly a gtk2 issue. Look around comment #30 onwards in that thread. There are simple fixes there for this crash.
Will a patch be rolled out to correct this issue in RHEL5.1 Enterprise Server in the future to correct it without having to hack the system so to speak?