The most interesting feature of this bug isn't that loading websites crashes it, it's that it's fairly non-deterministic and has a workaround (that is NOT convenient). If I visit a website and it crashes Firefox 2, it will continue to crash Firefox 2 every visit UNTIL I, very quickly after clicking the link/hitting enter, click the "Quit Firefox" button (the top-right-most button). Any website that was crashing Firefox 2 will then work properly while the dialog box asking me if I'm sure is up, then I can cancel and surf the net as before. Except then another website, perhaps a link off a google search or my e-mail or gentoo.org (it truly is random, with the exception that about:blank hasn't crashed me *yet*), will take Firefox down again. It's quite an aggravation. I don't even know what else to say about this bug's behavior. emerge --info Portage 2.1.1 (default-linux/x86/2006.0, gcc-4.1.1, glibc-2.4-r3, 2.6.17-gentoo- r8 i686) ================================================================= System uname: 2.6.17-gentoo-r8 i686 Intel(R) Pentium(R) 4 CPU 3.20GHz Gentoo Base System version 1.12.5 Last Sync: Thu, 26 Oct 2006 00:20:01 +0000 app-admin/eselect-compiler: [Not Present] dev-java/java-config: 1.2.11-r1 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r4 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -O2 -pipe -ffast-math" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/terminfo" CXXFLAGS="-march=pentium4 -O2 -pipe -ffast-math" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.cites.uiuc.edu/pub/gentoo ftp://gentoo.cites.uiuc. edu/pub/gentoo/ ftp://gentoo.chem.wisc.edu/gentoo/ ftp://gentoo.mirrors.tds.net/ gentoo ftp://gentoo.mirrors.pair.com/ ftp://gentoo.netnitco.net/pub/mirrors/gent oo/source/ http://mirror.uni-c.dk/pub/gentoo/" LANG="en_US.utf8" LC_ALL="en_US.UTF8" LINGUAS="" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/d istfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="x86 X a52 aac acpi aim alsa apache2 apm asf audacious automount bash-comple tion berkdb bidi bitmap-fonts cdr cjk cli cracklib crypt cups divx dlloader dri dvd dvdr dvdread elibc_glibc emboss encode firefox foomaticdb fortran fuse gdbm gif gpm gstreamer gtk gtk2 idn imlib input_devices_evdev input_devices_joystick input_devices_keyboard input_devices_mouse ipod isdnlog jabber javascript joysti ck jpeg kernel_linux libg++ libwww mad mikmod mmx mmxext motif mp3 mpeg msn ncur ses nls no-helper nptl nptlonly nsplugin ogg opengl openssh oscar oss pam pcmcia pcre perl png pppd python quicktime rdesktop readline real reflection reiser4 r eiserfs samba sdl session slp spell spl sse sse2 ssl stream subtitles tcpd theor a timidity truetype truetype-fonts type1-fonts udev unicode userland_GNU v4l v4l 2 video_cards_fglrx video_cards_radeon video_cards_vesa video_cards_vga vorbis w ifi win32codecs wma wmp xinerama xml xorg xv xvid zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA _OPTS
This does not seem to happen with the official Mozilla Firefox binary.
without a proper backtrace this bug is useless.
(In reply to comment #2) > without a proper backtrace this bug is useless. > Without instructions on how to make GDB actually *work* with Firefox when all I get is crap about /usr/bin/firefox is "/usr/bin/firefox": not in executable format: File format not recognized" and I can't get gdb to run off of mozilla-launcher either, your comment is also useless. I'd be delighted to provide you with a backtrace, if I could get Firefox to run in GDB.
always connect to gdb via full path not a bash script ... /usr/lib/mozilla-firefox/firefox-bin will do the trick for gdb.
(In reply to comment #4) > always connect to gdb via full path not a bash script ... > /usr/lib/mozilla-firefox/firefox-bin will do the trick for gdb. > It seems to have been crashing in mplayerplugin, even on sites with no media. I unmerged it and the crashing seems to have stopped. I'll re-open if it starts crashing again (which would indicate that wasn't the problem after all)
(In reply to comment #5) > It seems to have been crashing in mplayerplugin, even on sites with no media. > I unmerged it and the crashing seems to have stopped. I'll re-open if it > starts crashing again (which would indicate that wasn't the problem after all) > This is usually caused from not rebuilding the package against latest version of firefox. The ebuild tells you to rebuild all packages that are built against firefox.
(In reply to comment #6) > (In reply to comment #5) > > It seems to have been crashing in mplayerplugin, even on sites with no media. > > I unmerged it and the crashing seems to have stopped. I'll re-open if it > > starts crashing again (which would indicate that wasn't the problem after all) > > > > This is usually caused from not rebuilding the package against latest version > of firefox. The ebuild tells you to rebuild all packages that are built against > firefox. > Upon reading this message, I closed Firefox, rebuilt mplayerplug-in, and restarted Firefox. Firefox immediately crashed. I tried again. Firefox immediately crashed. Three more times. Firefox crashed. I re-unemerged mplayerplug-in. Firefox did not crash. I did build it against Firefox 2 as no other version of Firefox exists on my system. mplayerplug-in 3.31-r1 crashes Firefox like none other.
