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.

I tried on F7 installation and immediately got

/usr/lib/firefox-2.0.0.4/mozilla-remote-client -a firefox ; echo $?
Segmentation fault
139

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. 

Yeah, just a low priority issue as this isn't really the way people should be
using that... Probably best to push this upstream.

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.]

Fedora 7 now is using firefox-2.0.0.10 and a command 

 /usr/lib/firefox-2.0.0.10/mozilla-xremote-client -a firefox

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

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

 /usr/lib/firefox-1.5.0.12/mozilla-xremote-client -a firefox

I immediately got 1.9M of a core file.  It looks like that with
RHEL this can be reproduced at will.

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.

> 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-1.5.0.12-0.10.  Still with
firefox-debuginfo-1.5.0.12-0.10.el4.i386.rpm 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-1.5.0.12/mozilla-xremote-client -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 ?? ()
(gdb) 

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.

I have no clue about CentOS but just short Googling for "centos debuginfo" gave
me some hits. Please, try again.

> 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-2.0.0.10/mozilla-xremote-client -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
http://www.carbonetti.org/pub/linux/0/centos-debuginfo/
http://www.dcl-arch.org/pub/linux/0/centos-debuginfo/

There is a catch.  The latest one on both is
firefox-debuginfo-1.5.0.12-0.7.el4.centos.i386.rpm from 2007-10-20
while the current here is firefox-1.5.0.12-0.10.el4.centos from
2008-02-08.

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.

"Copy and waste". Sigh.  The command in the previous comment should
read '/usr/lib/firefox-1.5.0.12/mozilla-xremote-client -a firefox'.

Created attachment 295855 [details]
backtrace of firefox

Yup, I can reproduce this with RHEL5 and firefox-debuginfo-1.5.0.12-11.el5_1
firefox-1.5.0.12-11.el5_1, 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.

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-1.5.0.12/mozilla-xremote-client
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-1.5.0.12/mozilla-xremote-client -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 ()
(gdb) 

> 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.

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.

> 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.

That's possible. Closing as WONTFIX for RHEL-5.