Bug 452610 - Firefox 3.0 Beta 5 Segmentation Faults
Firefox 3.0 Beta 5 Segmentation Faults
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: firefox (Show other bugs)
i386 Linux
low Severity high
: rc
: ---
Assigned To: Gecko Maintainer
Depends On:
  Show dependency treegraph
Reported: 2008-06-23 21:41 EDT by Ed Greshko
Modified: 2008-07-03 08:56 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-07-03 08:56:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Core file from segfault (4.85 MB, application/octet-stream)
2008-06-23 21:41 EDT, Ed Greshko
no flags Details

  None (edit)
Description Ed Greshko 2008-06-23 21:41:22 EDT
Description of problem: Firefox seg faults on certain URLs

Version-Release number of selected component (if applicable):

How reproducible: Visit http://metocph.nmci.navy.mil/jtwc.php

Steps to Reproduce:
1. Bring up FF and visit http://metocph.nmci.navy.mil/jtwc.php
Actual results:

Expected results:

Additional info: This also fails on a RHELv4.6 system with only FF updated from
the beta channel.
Comment 1 Ed Greshko 2008-06-23 21:41:23 EDT
Created attachment 310097 [details]
Core file from segfault
Comment 2 Matěj Cepl 2008-06-25 05:38:51 EDT
Thanks for the bug report.  We have reviewed the information you have provided
above, and there is some additional information we require that will be helpful
in our diagnosis of this issue.

Please get your system to some released state (RHEL4.6 or 4.7), and then install
-debuginfo rpm for firefox (see
http://people.redhat.com/duffy/debuginfo/index-js.html for the way how to get
-debuginfo rpms).

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.

Please, include in the comment of this bug also output of the command

rpm -qa \*firefox\* \*plug\* \*xulrun\* \*flash\*

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.
Comment 3 Ed Greshko 2008-06-25 06:02:47 EDT
I went to the URL http://people.redhat.com/duffy/debuginfo/index-js.html and was
unable to find any debuginfo rpm's for firefox-3.0-0.beta5.3.el4.

Please point me to the correct place to pick this up.
Comment 4 Matěj Cepl 2008-06-25 10:21:49 EDT
OK, so the probably best way would be to wait for the final release of
fedora-3.0-1 which will happen in next few days, then you will have -debuginfo
on ftp.redhat.com and everything will me less complicated. Please, try it when
it will be available, and let us know.

In meantime, you can also try upstream binary from
Does it break for you as well?

Thank you for your cooperation.
Comment 5 Ed Greshko 2008-06-25 22:53:35 EDT
If I use the Mozilla released FF 3.0 binary with the evolution28 libpangocairo
it will crash on startup.  (I added /usr/evolution28/lib to ldconfig's path).

If I use libpangocairo from frysk it will fail while loading a page with the error:

/usr/local/firefox/firefox-bin: symbol lookup error:
/usr/local/firefox/libxul.so: undefined symbol: FT_GlyphSlot_Embolden
Comment 6 Martin Stransky 2008-06-26 05:51:00 EDT
firefox-3.0-1.el4 (final) should be released in next 4.7 beta snapshot 5, please
check it after release.
Comment 7 Ed Greshko 2008-07-02 20:21:09 EDT
It seems as if the latest update of freetype has fixed the crash.  However, ff3
(released version 3.0) will crash with a segfault on Quit.  I moved my
.mozilla/firefox directory out of the way and created a new one and even after
adding in all the themes and extensions it no longer crashes on quit.

So, the question is...  Do you want to continue looking into this or close it as
an anomaly? 
Comment 8 Matěj Cepl 2008-07-03 08:56:36 EDT
If this is really the corruption of ~/.mozilla directory problem, than I am
afraid we will give up on this.

Closing as NOTABUG (anymore).

Note You need to log in before you can comment on or make changes to this bug.