Bug 208031 - firefox - "Segmentation fault" from mozilla-xremote-client
firefox - "Segmentation fault" from mozilla-xremote-client
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: firefox (Show other bugs)
All Linux
low Severity high
: ---
: ---
Assigned To: Gecko Maintainer
massRequestForReproduction, RHEL-like
Depends On:
  Show dependency treegraph
Reported: 2006-09-25 18:37 EDT by Michal Jaegermann
Modified: 2008-02-29 08:27 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-29 08:27:23 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
backtrace of firefox (2.01 KB, text/plain)
2008-02-25 17:55 EST, Matěj Cepl
no flags Details

  None (edit)
Description Michal Jaegermann 2006-09-25 18:37:04 EDT
Description of problem:

With a firexfox already running watch this:

$ /usr/lib/firefox- -a firefox ; echo $?
Segmentation fault

Yes, I know that this is an imcomplete command but that is not
the point.

If after the first segmentation fault you will repeat the above then
now will be a long timeout and after that:

$ /usr/lib/firefox- -a firefox ; echo $?
/usr/lib/firefox- Error: Failed to send command:
No error string reported..

To get a segmentation fault you have to restart firefox again.

With firefox not running there will be simply "Failed to find a running
server" and no fireworks.

Actually seamonkey is doing the same too.

Version-Release number of selected component (if applicable):
firefox- from rawhide as well

How reproducible:
always in circumstances described
Comment 1 Matěj Cepl 2007-07-18 13:29:59 EDT
Fedora Core 5 is no longer supported, could you please reproduce this with the
updated version of the currently supported distribution (Fedora Core 6, or
Fedora 7, or Rawhide)? If this issue turns out to still be reproducible, please
let us know in this bug report.  If after a month's time we have not heard back
from you, we will have to close this bug as CANTFIX.

Setting status to NEEDINFO, and awaiting information from the reporter.

Thanks in advance.
Comment 2 Michal Jaegermann 2007-07-18 17:18:07 EDT
I tried on F7 installation and immediately got

/usr/lib/firefox- -a firefox ; echo $?
Segmentation fault

exactly like in the original report with "Failed to send command"
on subsequent tries.  Why you will not check that for yourself?

How I bumped into that I do not remember after ten months
but segfault is still there. 
Comment 3 Christopher Aillon 2007-08-07 12:33:36 EDT
Yeah, just a low priority issue as this isn't really the way people should be
using that... Probably best to push this upstream.
Comment 5 Matěj Cepl 2008-02-08 15:42:03 EST
Since this bugzilla report was filed, we have seriously upgraded Gecko-related
packages, which may have resolved this issue. Users who have experienced this
problem are encouraged to upgrade their system to the latest version of their
distribution available.

Please, confirm to us that this bug is reproducible on the latest upgrade of the
supported distribution (that's RHEL, or Fedora 7, 8, and Rawhide).

Setting the bug to NEEDINFO. If I won't get confirmation of reproducability in
30 days, the bug will be closed as INSUFFICIENT_DATA.

[This is mass-changing of bugs which seem to be too old and irrelevant anymore;
we are sorry, if this bug should not be incldued.]
Comment 6 Michal Jaegermann 2008-02-09 15:20:23 EST
Fedora 7 now is using firefox- and a command 

 /usr/lib/firefox- -a firefox

just sits there and is doing nothing (fully expected and good).

OTOH I tried the same on a CentOS installation with firefox-
By setting to "unlimited" a core limit after

 /usr/lib/firefox- -a firefox

I immediately got 1.9M of a core file.  It looks like that with
RHEL this can be reproduced at will.
Comment 7 Matěj Cepl 2008-02-11 18:21:00 EST
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 (concerning the bug on CentOS, of course):

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.
Comment 8 Michal Jaegermann 2008-02-24 18:01:26 EST
> Please install firefox-debuginfo

There is a problem, I am afraid.  I do not see an CentOS repositories
which would provide firefox-debuginfo and I do not have RHEL executables
of firefox-  Still with
firefox-debuginfo- added to the mix
if I am trying to run the command as specified under gdb then
I see:

(gdb) run
Starting program: /usr/lib/firefox- -a firefox
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1208706848 (LWP 24292)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208706848 (LWP 24292)]
0x08049bae in ?? ()
(gdb) where
#0  0x08049bae in ?? ()
#1  0x0804a130 in ?? ()
#2  0x01000085 in ?? ()
#3  0x00000000 in ?? ()

If this is a question of discrepancies between executables and
debugging info then a person with an access to right ingredients,
and with all information provided, should not have any trouble
to reproduce the issue.
Comment 9 Matěj Cepl 2008-02-25 12:37:13 EST
I have no clue about CentOS but just short Googling for "centos debuginfo" gave
me some hits. Please, try again.
Comment 10 Michal Jaegermann 2008-02-25 14:00:29 EST
> I have no clue about CentOS
But you likely have an access to RHEL installation and I would be
really surprised if you could not easily reproduce the bug.  Again:
   - start firefox
   - run '/usr/lib/firefox- -a firefox'
   - SIGSEGV happens only the first time and NOT when you are repeating
     the command in question without restarting firefox process.

So what is the problem with trying???

> just short Googling for "centos debuginfo" gave me some hits

Indeed.  That gives me exactly _two_ locations with debuginfo packages

There is a catch.  The latest one on both is
firefox-debuginfo- from 2007-10-20
while the current here is firefox- from

No idea if I have enough of a disk space to try to recompile
a corresponding firefox.  In any case this will not happen right away.
Besides this smells like a bomb in libraries, most likely some
string function, and with all that threading this may not help
that much.
Comment 11 Michal Jaegermann 2008-02-25 14:01:44 EST
"Copy and waste". Sigh.  The command in the previous comment should
read '/usr/lib/firefox- -a firefox'.
Comment 12 Matěj Cepl 2008-02-25 17:55:38 EST
Created attachment 295855 [details]
backtrace of firefox

Yup, I can reproduce this with RHEL5 and firefox-debuginfo-
firefox-, but I haven't got any crash backtraces. So at least
I have stopped (with Ctrl-X) firefox running inside of gdb after the second
error of mozilla-xremote-licent and captured what’s attached.
Comment 13 Matěj Cepl 2008-02-25 17:58:39 EST
OK, but this is better. When running mozilla-xremote-client for the first time
in gdb, I got this backtrace:

[matej@tikanga ~]$ gdb /usr/lib/firefox-
GNU gdb Red Hat Linux (6.5-25.el5_1.1rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db
library "/lib/libthread_db.so.1".

(gdb) run -a firefox 
Starting program: /usr/lib/firefox- -a firefox
[Thread debugging using libthread_db enabled]
[New Thread -1208858400 (LWP 2280)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208858400 (LWP 2280)]
0x08049265 in XRemoteClient::DoSendCommand (this=0xbffa5938, aWindow=33554559, 
    aCommand=0x0, aResponse=0xbffa5970, aDestroyed=0xbffa58e8)
    at XRemoteClient.cpp:656
656	           strlen(aCommand));
(gdb) thread apply all backtrace

Thread 1 (Thread -1208858400 (LWP 2280)):
#0  0x08049265 in XRemoteClient::DoSendCommand (this=0xbffa5938, 
    aWindow=33554559, aCommand=0x0, aResponse=0xbffa5970, 
    aDestroyed=0xbffa58e8) at XRemoteClient.cpp:656
#1  0x08049bce in XRemoteClient::SendCommand (this=0xbffa5938, 
    aProgram=0x8c1d498 "firefox", aUsername=0x0, aProfile=0x0, aCommand=0x0, 
    aResponse=0xbffa5970, aWindowFound=0xbffa5974) at XRemoteClient.cpp:201
#2  0x08048e22 in main (argc=Cannot access memory at address 0xffffffff
) at mozilla-xremote-client.cpp:103
#3  0x00116dec in __libc_start_main () from /lib/libc.so.6
#4  0x08048bf1 in _start ()
Comment 14 Michal Jaegermann 2008-02-25 18:44:52 EST
> OK, but this is better
Sure. :-)  Thanks for reproducing that on your system (although
this could have been done a long time ago).

A bomb with 'strlen(aCommand)' around is sort of expected in
the context; and not that surprising with aCommand=0x0. One
wonders what other nonsense can be passed there.
Comment 15 Martin Stransky 2008-02-26 04:14:36 EST
mozilla-xremote-client is not included in the upcoming firefox-3 package for
RHEL-5 so I think this bug can be closed as WONTFIX.
Comment 16 Michal Jaegermann 2008-02-26 10:39:47 EST
> upcoming firefox-3 package for RHEL-5
Does this apply to RHEL-4 as well?

I think that the bug is pretty obscure; the only issue is that
problems of that sort rather show symptoms and over time tend
to escalate to security bugs.
Comment 17 Martin Stransky 2008-02-29 08:27:23 EST
That's possible. Closing as WONTFIX for RHEL-5.

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