This bug occours with glibc 2.3.4, maybe also with glibc 2.3.5 (different callstack, so can't judge), both with Gentoo patches of course. The problem is the glibc library calls calloc when it is being initialized, this can cause problems with other programs that want to find memory leaks and provide their own malloc/calloc/etc. functions. This problem was found with Mozilla and trace-malloc enabled, see https://bugzilla.mozilla.org/show_bug.cgi?id=295159 for reference. We don't know yet if this is a Gentoo-only problem, i can ask the bug reporter of that bug (if you want) if he could install a official glibc version (which might get difficult ;). But so far no other people filed bugs under bugzilla.mozilla.org about crashing with other distributions upon startup with trace-malloc enabled.
chances are it's the ssp guard initializing, put that shouldnt be causing any problems
nothing in the ssp startup uses any brk/malloc/calloc directly. And I'm pretty sure not indirectly either.
sorry, but i really know nothing about firefox internals ... how do i do the step to reproduce ? 1. Add "ac_add_options --enable-trace-malloc" to your mozconfig
./sysdeps/generic/dl-tls.c in glibc 2.3.5 (with gentoo patches) calls calloc during init, while ./sysdeps/generic/libc-tls.c does not. (Look at the dl_tls_setup for those who don't know which function we are talking about).
i just unpacked both glibc-2.3.5 and glibc-2.3.5-r1 and neither call calloc in ./sysdeps/generic/libc-tls.c
And you did apply all gentoo patches? # emerge -pv glibc These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] sys-libs/glibc-2.3.5 -build -debug -erandom -hardened (-multilib) +nls +nptl -nptlonly +pic (-selinux) -userlocales 0 kB I just started emerge and hit ctrl-c when "source unpacked" message appeared when I started my grepping.
(In reply to comment #5) > i just unpacked both glibc-2.3.5 and glibc-2.3.5-r1 and neither call > calloc in ./sysdeps/generic/libc-tls.c btw, dl-tls.c calls calloc, while libc-tls.c doesn't.
(In reply to comment #6) > And you did apply all gentoo patches? i said i unpacked the ebuild, that means i did: $ ebuild glibc-2.3.5.ebuild clean unpack $ grep calloc libc-tls.c <no results because libc-tls.c does not call calloc> $ ebuild glibc-2.3.5-r1.ebuild clean unpack $ grep calloc libc-tls.c <no results because libc-tls.c does not call calloc> (In reply to comment #7) > btw, dl-tls.c calls calloc, while libc-tls.c doesn't. so in other words, everytime you said 'libc-tls.c' you really meant 'dl-tls.c' ? the calloc in dl-tls.c does not come from any Gentoo patches, that is part of the upstream glibc tree
Without emerge info and steps to reproduce this is a waste .. I personally say it should be closed with NEEDINFO until report decided to provide info to reproduce.
Eh? I cannot provide more info since i don't use Gentoo, but it seems two other people here are already on it (looking for more info). If it's a Gentoo bug caused by a patch on the original glibc source, ok, if not, please say so and i'll forward this bug to the glibc mailing list.
Ok i just downloaded the glibc 2.3.4 tarball from http://ftp.gnu.org/gnu/glibc/ and it seems calloc is already used there in _dl_tls_setup. So i think you can resolve this bug here since this is a bug in glibc.
see comment #3 for the info i want from you :)
Normally when you want to build Firefox, you have a file named .mozconfig which contains the configure and make options for building. So if you really want to reproduce this, do this: Visit http://www.mozilla.org/build/ and follow the instructions, for point 3 your .mozconfig should look like this: . $topsrcdir/browser/config/mozconfig ac_add_options --enable-trace-malloc But before you try building, you have to manually check out mozilla/tools/trace-malloc from CVS.
Is this still an issue with the newest glibc's? Do we plan on fixing it or should we close this as wontfix?
a WONTFIX says we know this is a bug in our glibc and we dont care
They wontfix'ed the bug in the upstream glibc (oh wonder...), so you can resolve the bug here, too (as INVALID or WONTFIX, whatever you use over here).
As per comment #16, upstream said this is a WONTFIX.
