Summary: | glibc uses calloc upon initialization | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Frank Wein <bugzilla> |
Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | hardened, mozilla, stian |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
URL: | https://bugzilla.mozilla.org/show_bug.cgi?id=295159 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Frank Wein
2005-05-23 14:17:41 UTC
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. |