If the gnome-vfs-2.8.1 libraries are present (and presumably if mozilla-firefox was compiled with USE=gnome), mozilla-firefox-1.0_pre-r1,-r2 hangs when you try to make a download or save an image. No such problems occur with gnome-vfs-2.6.2 Re-emerging firefox did not solve this problem. Reproducible: Always Steps to Reproduce: 1. USE=gnome emerge mozilla-firefox 2. open up any page 3. try to save an image or download a file Actual Results: firefox freezes Expected Results: image saved or document downloaded successfully mozilla-firefox-1.0_pre-r2 was compiled with USE="-debug +gnome +gtk2 -ipv6 +java +ldap +mozdevelop -moznoxft +mozxmlterm +truetype +xinerama +xprint" gnome-vfs-2.8.1 was compiled with USE="-debug +doc -gnutls -hal +howl -ipv6 +samba +ssl" gnome-vfs-2.6.2 was compiled with USE="-debug +doc -gnutls -ipv6 +samba +ssl" Compiler is gcc-3.4.2-r2 hardened. Portage 2.0.51_rc7 (default-x86-1.4, gcc-3.4.2, glibc-2.3.3.20040420-r1, 2.6.8-gentoo i686) System uname: 2.6.8-gentoo i686 AMD Athlon(tm) XP 2500+ Gentoo Base System version 1.4.16 distcc 2.17 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.14.90.0.8-r1 Headers: sys-kernel/linux26-headers-2.6.8.1 Libtools: sys-devel/libtool-1.5.2-r5 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -O2 -pipe -frename-registers -fomit-frame-pointer " CHOST="i686-pc-linux-gnu"
Hi, Had something similar a week or two back. What's the output of gcc-config -l? Normally you should get list of available profiles, maybe such: ... [1] i686-pc-linux-gnu-3.3.4 [2] i686-pc-linux-gnu-3.4.2-r2 ... Using hardened profile too. If you get an error saying that can't fine profile the problem is with GCC-3.4.2. There is resolved BUG with this error. Also you have 'old' version of binutils-0.14.... i'm using 0.15... Same applies to glibc-2.3.3-20040420 (mine is glibc-2.3.4-20040808..) PS:last two lines may be OT here. Also using an 'old' profile - 1.4. Some things in your system are quite new (GCC) other are rather old (binutils,glibc, profile). Any info in the logs? This is just a shot in the dark. HTH Rumen
Re Rumen: $ gcc-config -l [1] i686-pc-linux-gnu-3.3.4 [2] i686-pc-linux-gnu-3.4.2 [3] i686-pc-linux-gnu-3.4.2-hardenednossp [4] i686-pc-linux-gnu-3.4.2-vanilla I am using glibc 20040420 because I haven't been able to compile any later ones (they all fail maketest, so I don't want to risk installing them). My binutils are up-to-date in x86. There is nothing interesting in the logs. And I am using 1.4 profile because I've been running gentoo since early 2003 - and it hasn't caused any problems so far.
OK, this is *not* a problem with firefox - this is simply a bug in gnome-vfs-2.8.1 that happened to get triggered by firefox on my system (mozilla, nautilus, and a few gnome apps trigger it also). In eggdesktopentries.c we have : if (!q) country_len = q - p; else country_len = strlen (p); if (country_len <= 0) return NULL; country = g_new (gchar, country_len + 1); where q is NULL or a substring of p, and the goal is to set country_len to be the length of the part of p that precedes q. Clearly this doesn't work - if q is NULL, country_len gets set to q-p = 0 - (some address) = really_big_number, and we overflow badly in g_new. To get the correct behavior, we need to switch the order of the two assignments of country_len.
Created attachment 42663 [details, diff] gnome-vfs-2.8.1-locale_parsing.patch Patch to cure the bug (locale parsing in .desktop files overflows g_new) described above
Created attachment 42664 [details] gnome-vfs-2.8.1-r1.ebuild ebuild to use the patch
this was reported upstream as http://bugzilla.gnome.org/show_bug.cgi?id=153759 i used the complete patch from upstream for gnome-vfs-2.8.1-r1 thanks for the report & investigation