I have the same situation as described in Bug #64596 <http://bugs.gentoo.org/show_bug.cgi?id=64596> This is, however, with net-www/mozilla-firefox-1.0 and, so, I haven't the luxury of upgrading to a new version that mysteriously fixes the issue ;) When I first login to an X session and open firefox, it takes a little longer to start than normal, lanches a window and immediately exits. Subsequent attempts to start firefox will succeed as expected. (A thought: perhaps the first launch *fixes* a circumstance such as a library initialization, or a missing/defunct lock-file/symlink?) Reproducible: Always Steps to Reproduce: 1. Login to an X session 2. Type: /usr/bin/firefox & 3. Type: /usr/bin/firefox & Actual Results: # Result of Step 2: (Output:) No running windows found /usr/bin/firefox: line 392: <pid> Killed $mozbin "$@" # Result of Step 3: Everything runs fine... Expected Results: # Results of Step 2 should have been: Everything runs fine... # Result of "emerge info": (Output:) Portage 2.0.51-r2 (default-linux/x86/2004.3, gcc-3.3.4, glibc-2.3.4.20040808-r1, 2.6.9-gentoo-r4 i686) ================================================================= System uname: 2.6.9-gentoo-r4 i686 Celeron (Coppermine) Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.14.90.0.8-r1 Headers: sys-kernel/linux-headers-2.4.21-r1 Libtools: sys-devel/libtool-1.5.2-r7 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=pentium3 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=pentium3 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms" GENTOO_MIRRORS="ftp://gentoo.mirrors.pair.com/ ftp://gentoo.ccccom.com ftp://mirrors.tds.net/gentoo ftp://ftp.ndlug.nd.edu/pub/gentoo/ ftp://chod.cwru.edu/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X aalib aim alsa apache2 apm arts audiofile bash-completion bitmap-fonts bzlib cdr crypt cups encode esd f77 fam fbcon foomaticdb fortran ftp gd gif gpm gtk gtk2 imagemagick imlib jpeg kde lcms lesstif libg++ libwww mad mime motif mozilla mpeg mysql mysqli nas ncurses nls oggvorbis openal opengl oscar pam pcre pdflib perl php png pnp postgres python qt quicktime readline scanner sdl slang sockets spell ssl svg svga tcpd tidy tiff truetype usb vhosts x86 xml2 xmms xpm xsl xv zlib"
Created attachment 45062 [details] bad me :) cd /usr/bin/ ; strace ./firefox > ~/foo.txt 2>&1
Comment on attachment 45062 [details] bad me :) strace was on success, brb, will redo on failed launch
Created attachment 45065 [details] strace BTW: hate that you can't remove your own screwed up commits in bugzilla ;p This was done on the invocation in which firefox did crash...
Just wondering if this bug is being looked into ;) Is there any more info I could provide to help determine the cause? FYI: I have scoured the mozilla.org bugzilla for product firefox and have yet to find a bug describing this issue (open or closed), so I am thinking it may not be a bug *in* mozilla itself.
I had the same symptoms. Unmerged firefox, which broke thunderbird. Remerged thunderbird (now working), installed binary firefox from mozilla(now working). Conflict between firefox and thunderbird ebuilds?
I did not have Thunderbird instaled when I reported the issue. I have since updated to Firefox 1.0.4 via ebuild and the issue no longer affects this system, but another system I have that is still running the Firefox 1.0 ebuild does show this behavior consistently. I have not found any related issues running the official Mozilla.org Firefox 1.0 binaries or source compiled versions for other distros. I think it was a bug in either the Firefox 1.0 ebuild or another ebuild which Firefox interacts with/depends on. In any event, updgrading to a newer version ebuild fixed the problem.
