Red Hat Bugzilla – Bug 430140
Firefox crashes frequently sometimes on flash sites or not
Last modified: 2008-03-04 15:46:09 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.4 (like Gecko)
Description of problem:
Have been experiencing frequent crashes of Firefox (my box and others I
administer). I usually always can get it to crash when visiting a Flash
related site (like any under the www.adobe.com site) but even then it might
take a few tries to get it to crash. Firefox will also crash when not even
visiting a Flash related site and it has been so random as when I have
returned to work in the morning, Firefox has crashed for no apparent reason.
When running through the gdb debugger, most of the backtraces point to a flash
(?) related problem (ie "Flash_EnforceLocalSecurity"), whether a visiting a
Flash site or not. I am attaching a full backtrace of a crash.
I have seen this behavior on Profiles with no Extensions or Themes installed
and on a newly setup ("clean") Profile. Some users see crashes more
sporadically then others, and of course, different individuals will have
different preference settings etc. but the consistent thing is that all the
machines were imaged from the same source image so the basic firefox/flash
setup should be the same, and further, none of these issues were happening in
RH4 Firefox and Flash (with current Profiles).
Version-Release number of selected component (if applicable):
firefox-184.108.40.206-7.el5 kernel-2.6.18-53.1.4.el5 flash-plugin-220.127.116.11-1.el5
Steps to Reproduce:
2. visit a Flash related site or,
3. do nothing specific and eventually Firefox will crash
Firefox doesn't crash.
When running directly from the command line, Firefox gives no errors. Checks
of system logs and SE Linux troubleshooter shows no errors.
Created attachment 292842 [details]
backtrace of Firefox crash
Created attachment 292846 [details]
another backtrace of Firefox crashing
Did not take long for Firefox to crash again, this time no Flash page were
directly involved but was clicking around in another page.
For official Red Hat Enterprise Linux support, please log into the Red Hat
support website at http://www.redhat.com/support and file a support ticket, or
alternatively contact Red Hat Global Support Services at 1-888-RED-HAT1 to speak
directly with a support associate and escalate an issue.
I have submitted a support request.
OK, let me know when/if your problem will be escalated to the bugzilla.
I just thought I'd pass this along. I posted some information regarding a
well-known (non-flash related, as far as I can tell) firefox crash on RHEL5/5.1
in bug 244530 (comment #2). Some of the info at the links might be useful in
thanks for the input and the links. I did not see anything in those links to try
that I haven't already tried.... and still, Firefox crashes frequently enough to
make it rather irritating. At least visiting those sites confirmed that this is
not an isolated problem to our environment.
it might be useful in isolating the problem. Hopefully it'll help. For me the
problem happens rarely but, when it does, I am usually saving something from the
browser (save page as, save image as, save link as etc). If it crashes it will
happen as soon as the save window opens. When I restore session (firefox 2),
everything works normally.
Have you tried running the firefox 3 beta? I noticed on a few bug reporting
sites that there are claims it is more stable under RHEL.
I rarely do "saves" from the browser so I cant speak to that issue; my (my
"users") crashes have come from a variety of actions and non-actions. In fact,
it just crashed on my first attempt to write this by simply clicking around in
the RHN site for some info.
Due to our environment and the fact we pay Redhat (for licenses, support, etc)
we generally stick to the mainline RH distributed releases, such as 1.5xxx for
firefox. Frankly, I would think a downlevel "stable" version should be more
reliable then an uplevel beta. This is compoundly confusing when we see no
problems with firefox 1.5x crashes on RHEL 4 (only RHEL 5).
RH did release a critical patch for Firefox today... but since my system has
already crashed since installing it, I can not be too optimistic that it has
fixed the crash issues we are seeing.
For me ... *everyone* should see the following:
1) Install the flash-plugin
2) launch firefox and go to http://www.youtube.com/ ( or any flash site)
2) goto www.google.com , then www.math.wichita.edu, then www.fedoraproject.org,
and then www.redhat.com
( * you really only need to go to 4 places without flash and don't hit the
forward or back button )
3) now click on File -> Open File
Result: Firefox will crash.
Some Crash Features:
a) Any attempt to open a new dialog box ( add a new book mark, a webpage popup,
the browser complaing about a font, etc ) will crash firefox.
b) You have to visit 4 or more web pages. 1, 2 or 3 and you will not get a crash.
c) The java plugin shows the exact same bug.
d) You can prevent the crash by using File -> Open File and just canceling
immediately upon starting firefox. Then you don't get any crash.
I suppose the last thing (click on File -> Open File -> Cancel) with every
firefox start is a "workaround" to allow you to browse the web. Personally I've
tried compiling seamonkey and firefox 2 and I still get the same problem. I'm
pretty sure a variant of it is in Fedora as well.
If I had to guess the bug in in a mixing of firefox plugins starting threads,
firefox threads for dialogs, and the kernel's handeling of said threads.
I'm sorry to hear the update hasn't fixed your crashes. I'll try it out when it
comes out in the CentOS repositories. In case you do decide you want to
experiment with FF3 I wrote out a set of instructions in the second message here:
They are for FF2 but will work with very minor modification (all 2's -> 3's) for
FF3. This will keep your existing FF1.5xx intact (in fact, if you skip steps 9
your users wont even know that FF3 is installed. That way you could test it out
on one machine with just one account.)
I'm not sure it will help but thought I'd pass it along in case you want to try
it. If you'd like to correspond further please feel free to e-mail me.
Oh, one last thing. Could you e-mail me the link to the latest patch for FF1.5
patch from RedHat? I'd like to read up on the fixes.
P.S.- I just saw Mark's message here. This type of crashing on opening a save
dialog is exactly what I've been seeing. I wonder if one can write a script that
runs firefox and automatically "saves as and cancels" on startup :)
Mark, thanks for posting this. I think that will be useful in diagnosing for a
here is the link to the errate detail for latest FF patch:
if you can't view it, I can send separately via direct email.
Tried your crash procedure but did not crash. To me, goes to show how obscure
this can be...
So our latest theory here is... on (some of) our systems we may be bumping up
againest the maximum on the memory and the kernel kills firefox. This could
happen at the point where something in is done in Firefox that pushes past the
memory limit that the RH5 kernel "tolerates". This could be compounded if FF 1.5
has memory leaks/problems; whereas FF 3.x is being compeletely rearchitected...
which may explain why it performs better in some situations. We'll probably try
some tests here and turn on full kernel logging to see if we catch something.
this memory max out theory could explain why, at least at our location, some
users see way more crashes of unknown nature then others...
Jonathan, thanks for the link. It redirects me to the rhn login but I managed to
log in with an old rhn account which appears to still be active so I can view
Mark's method produces the crash for me on FF2. It gives the same exit code
(echo $? yields 139) that I've always been getting for my crashes.
(flash-blockers must be disabled as the actual flash needs to run). I also tried
it with firefox 3beta2 and it did not crash.
Google is my friend. :)
Seems this is a rather well seen bug in the firefox+plugin community. One fix
is at ...
It basically just adds a check for any empty callback. Like the author ( Todd
Whiteman ) states at their bugzilla: "works for the case where there is no
colormap, but will also stop legitimate callbacks that may not be using any
For me the 3 line fix stopped all of my known crash methods.
Thanks for finding this. I'm guessing you are talking about the file at
I have to admit my ignorance. How do I use this?
In case anyone else comes here looking for a potential fix to Firefox crashes,
the crash described in comment number 10 can be easily fixed. Please see the
It seems to be mainly a gtk2 issue. Look around comment #30 onwards in that thread.
We issued https://rhn.redhat.com/errata/RHBA-2008-0147.html to fix some of these
crashes, but we seem to have missed one, which is being tracked at:
*** This bug has been marked as a duplicate of 433823 ***