I've had the probleme for several months. I dont think the segfault is related to RAM because * none other package/software ever segfaulted on this server * this is 100% reproducible: the ebuild segfault at the same place each time (on my system, dietlibc is pulled as a dependancy for util-vserver) Reproducible: Always Steps to Reproduce: 1. emerge -u util-vserver Actual Results: make: *** [bin-x86_64/elftrunc] Segmentation fault I guess elftrunc is something build by dietlibc and then used later on during the build. My compiler is sys-devel/gcc-4.5.3-r1 with no fancy options (from make.conf:) CFLAGS="-march=native -O2 -pipe" I went to the build dir to check, don't know if that helps: verdi hollow-dietlibc-4e86d5e # pwd /tmp/portage/dev-libs/dietlibc-0.33_pre20110403/work/hollow-dietlibc-4e86d5e verdi hollow-dietlibc-4e86d5e # ./bin-x86_64/diet Segmentation fault (core dumped) verdi hollow-dietlibc-4e86d5e # gdb ./bin-x86_64/diet GNU gdb (Gentoo 7.2 p1) 7.2 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". For bug reporting instructions, please see: <http://bugs.gentoo.org/>... Reading symbols from /tmp/portage/dev-libs/dietlibc-0.33_pre20110403/work/hollow-dietlibc-4e86d5e/bin-x86_64/diet...(no debugging symbols found)...done. (gdb) run Starting program: /tmp/portage/dev-libs/dietlibc-0.33_pre20110403/work/hollow-dietlibc-4e86d5e/bin-x86_64/diet Program received signal SIGSEGV, Segmentation fault. 0x0000000000401ac7 in memcpy () (gdb) bt #0 0x0000000000401ac7 in memcpy () #1 0x000000000040182c in stackgap () #2 0x0000000000400188 in _start () (gdb)
Created attachment 310799 [details] build log
Created attachment 310801 [details] emerge --info
it still fails consistently here. Nobody else has this bug ??
even when recompiling bin-x86_64/diet without stripping i can't get a useful backtrace : verdi hollow-dietlibc-4e86d5e # pwd /tmp/portage/dev-libs/dietlibc-0.33_pre20110403/work/hollow-dietlibc-4e86d5e verdi hollow-dietlibc-4e86d5e # gcc -D__dietlibc__ -isystem include -fstrict-aliasing -momit-leaf-frame-pointer -mfancy-math-387 -W -Wall -Wextra -Wchar-subscripts -Wmissing-prototypes -Wmissing-declarations -Wno-switch -Wno-unused -Wredundant-decls -nostdlib -o bin-x86_64/diet bin-x86_64/start.o bin-x86_64/dyn_start.o diet.c bin-x86_64/dietlibc.a bin-x86_64/dyn_stop.o -DDIETHOME=\"/tmp/portage/dev-libs/dietlibc-0.33_pre20110403/work/hollow-dietlibc-4e86d5e\" -DVERSION=\"dietlibc-0.33\" -lgcc verdi hollow-dietlibc-4e86d5e # gdb bin-x86_64/diet GNU gdb (Gentoo 7.2 p1) 7.2 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". For bug reporting instructions, please see: <http://bugs.gentoo.org/>... Reading symbols from /tmp/portage/dev-libs/dietlibc-0.33_pre20110403/work/hollow-dietlibc-4e86d5e/bin-x86_64/diet...(no debugging symbols found)...done. (gdb) run Starting program: /tmp/portage/dev-libs/dietlibc-0.33_pre20110403/work/hollow-dietlibc-4e86d5e/bin-x86_64/diet Program received signal SIGSEGV, Segmentation fault. 0x0000000000401357 in memcpy () (gdb) bt #0 0x0000000000401357 in memcpy () #1 0x0000000000401c2c in stackgap () #2 0x0000000000400188 in _start () (gdb)
I have the same problem. Probably an hardened related one. About util-vserver it is possible to compile without dietlibc. For example by creating an overlay of util-vserver-0.30.216_pre3025.ebuild and changing lines : DEPEND=">=dev-libs/dietlibc-0.33_pre20110403 ${CDEPEND}" to : DEPEND="${CDEPEND}" After that util-vserver compile and run.
Ah, great to know, thanks for the tip. Just for the record : i DONT use hardened. My profile is default/linux/amd64/10.0/desktop
FIX : sorry, i messed up with my servers. The one i have showing this bug actually DOES use hardened (hardened/linux/amd64) (as seen in attached emerge --info, btw). So comment #5 might be true and the bug could be related to hardened
(In reply to comment #7) > FIX : sorry, i messed up with my servers. The one i have showing this bug > actually DOES use hardened (hardened/linux/amd64) (as seen in attached > emerge --info, btw). > > So comment #5 might be true and the bug could be related to hardened Have other servers (not hardened the same problem ?
Can't really say, as I've migrated all my servers to hardened not so long ago. As a test, i did "emerge util-vserver" on my desktop (non hardened), but it doesn't pull dietlibc. I'm really surprised by this, as dietlibc is explicitely cited in the ebuild, and I've checked that it is not already installed : orzel@berlioz /home/orzel% emerge util-vserver [ebuild N ] sys-cluster/util-vserver-0.30.216_pre3025 [ebuild N ] dev-libs/beecrypt-4.2.1 USE="cxx java python static-libs threads -doc" [ebuild N ] net-misc/vconfig-1.9 USE="-static" If i do 'emerge dietlibc', it works and emerge the exact same version that fails on hardened servers: orzel@berlioz /home/orzel% emerge dietlibc [ebuild N ] dev-libs/dietlibc-0.33_pre20110403 USE="-debug" Would you like to merge these packages? [Yes/No] >>> Verifying ebuild manifests >>> Emerging (1 of 1) dev-libs/dietlibc-0.33_pre20110403 >>> Jobs: 0 of 1 complete, 1 running Load avg: 0.52, 0.55, 0.41 >>> Installing (1 of 1) dev-libs/dietlibc-0.33_pre20110403 >>> Recording dev-libs/dietlibc in "world" favorites file... >>> Jobs: 1 of 1 complete What about your tests ? have you done any ? It's just a matter of "emerge util-vserver" (or dietlibc).
I got some weird behaviour here that might give hint on the reason for the missing dependancy. dietlibc is NOT installed on the system if i do "emerge -uN sys-cluster/util-vserver", it is NOT pulled on in the dependancy, as explained previously. There's another bug (#432044) related to util-vserver failing to build with bash-completion. I dont care about bash-completion, so i've copied util-vserver-0.30.216_pre3025.ebuild as util-vserver-0.30.216_pre3025-r1.ebuild on my local overlay and removed the two lines related to bash. And now, the exact same command "emerge -uN sys-cluster/util-vserver" DOES pull dietlibc in the dependancy list. So my (wild) guess is that the inherit "bash-completion-r1" stuff breaks dependancy.
bash-completion-r1.eclass does not touch/have any dependencies. i doubt that this is causing your problems. i've installed util-vserver on dozens of machines and could never reproduce this problem. but i'm also not using hardened, since it is a very bad choice for util-vserver and has never worked well. i'd recommend to remove all the hardened stuff (at least the toolchain stuff. hardened kernel should work)
Closed as "worksforme" ?? It's kinda easy i think. The bug is confirmed on hardened. You dont use hardened and it works for you.... so you close ? At least the bug should be renamed 'dietlibc doesn't compile on hardened' or something along those lines, shouldn't it ?
For those having this bug : i can confirm the workaround in comment 5 does work. Just remove the dietlibc dependancy in your overlay.
+*dietlibc-0.33_pre20130103 (03 Jan 2013) + + 03 Jan 2013; Pacho Ramos <pacho@gentoo.org> +dietlibc-0.33_pre20130103.ebuild: + Bump with snapshot taken today to get all the changes upstream did +
dev-libs/dietlibc-0.33_pre20130103 still fails with the same problem: verdi ~ # tail /tmp/portage/dev-libs/dietlibc-0.33_pre20130103/temp/build.log -n 20 R .comment -R .note bin-x86_64/diet make: R: Command not found make: [bin-x86_64/diet] Error 127 (ignored) bin-x86_64/diet x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -nostdinc -W -Wall -Wextra -Wchar-subscripts -Wmissing-prototypes -Wmissing-declarations -Wno-switch -Wno-unused -Wredundant-decls -fno-strict-aliasing -nopie -Wa,--noexecstack -o bin-x86_64/elftrunc contrib/elftrunc.c R .comment -R .note bin-x86_64/diet-i make: R: Command not found make: [bin-x86_64/diet-i] Error 127 (ignored) bin-x86_64/diet x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -nostdinc -W -Wall -Wextra -Wchar-subscripts -Wmissing-prototypes -Wmissing-declarations -Wno-switch -Wno-unused -Wredundant-decls -fno-strict-aliasing -nopie -Wa,--noexecstack -o bin-x86_64/dnsd contrib/dnsd.c make: *** [bin-x86_64/elftrunc] Segmentation fault make: *** Waiting for unfinished jobs.... make: *** [bin-x86_64/dnsd] Segmentation fault * ERROR: dev-libs/dietlibc-0.33_pre20130103 failed (compile phase): * emake failed * * If you need support, post the output of `emerge --info '=dev-libs/dietlibc-0.33_pre20130103'`, * the complete build log and the output of `emerge -pqv '=dev-libs/dietlibc-0.33_pre20130103'`. * The complete build log is located at '/usr/unsecure/tmp/portage/dev-libs/dietlibc-0.33_pre20130103/temp/build.log'. * The ebuild environment file is located at '/usr/unsecure/tmp/portage/dev-libs/dietlibc-0.33_pre20130103/temp/environment'. * Working directory: '/usr/unsecure/tmp/portage/dev-libs/dietlibc-0.33_pre20130103/work/dietlibc-0.33_pre20130103' * S: '/usr/unsecure/tmp/portage/dev-libs/dietlibc-0.33_pre20130103/work/dietlibc-0.33_pre20130103'
I still don't understand why this ticket is closed. dietlibc can't be emerged on hardened. The bug is there. The 'worksforme' is just plain wrong as it was tested on non-hardened and the bug is about failing on hardened.. ? People having the same problem wont find it when searching bugs.gentoo.org
(In reply to comment #16) > I still don't understand why this ticket is closed. dietlibc can't be > emerged on hardened. Then, why YOU mark this as fixed?!
Please attach updated full build.log
Created attachment 342594 [details] build log as of today
@pacho : i've updated the ebuild. Really nothing new there... did you really need this ? I don't know how to remove or 'mark obsoloate' the first attachment. @Sergey: don't be rude and please don't shout. I don't have permission to change the status, and I tried to change the resolution but couldn't. Actually i dont even understand how a ticket can have a Status of RESOLVED with a resolution of TEST-REQUEST.
(In reply to comment #20) > @Sergey: don't be rude and please don't shout. I don't have permission to > change the status, and I tried to change the resolution but couldn't. > Actually i dont even understand how a ticket can have a Status of RESOLVED > with a resolution of TEST-REQUEST. I am not rude(if you think that i am, then i am sorry for this misunderstanding). About RESOLVED TEST-REQUEST - try to look at this from our side - "we do things and problem is gone in our installation", that's why - RESOLVED. But problem may be too tricky and we could miss something, that's why - TEST-REQUEST: let the reporter try and mark it as FIXED himself(or say that it is not fixed, then WE will change the status accordingly).
I can also confirm this is only reproducible with a hardened profile. It appears to have been introduced in the 0.33 release. I've narrowed it down to the thread local storage implementation. Changelog[1] states: first stab at getting TLS to work in actual threads The segfault is on-exec of the diet executable. Execing the produced binary with gdb shows: Program received signal SIGSEGV, Segmentation fault. memcpy (dst=0x3bae9182f80, src=0x0, n=0) at lib/memcpy.c:9 9 lib/memcpy.c: No such file or directory. (gdb) bt #0 memcpy (dst=0x3bae9182f80, src=0x0, n=0) at lib/memcpy.c:9 #1 0x0000000000401a1b in stackgap (argc=1, argv=0x3bae918e478, envp=0x3bae918e488) at lib/stackgap.c:181 #2 0x0000000000400fe2 in _start () at x86_64/start.S:41 (gdb) q Line 181 in lib/stackgap.c is surrounded by #ifdef WANT_TLS : memcpy(tlsdata,__tdataptr,__tdatasize); GDB shows that __tdataptr is NULL and __tdatasize is 0. [1] http://www.fefe.de/dietlibc/changes-0.33.txt
Probably not helping so much but I can build it using FEATURES="-sandbox -usersandbox" which is not really the best solution. Can't this but be link to 369147 ?
Can some test to build it with gcc 4.8.2 hardened?
Sorry, can't test here. I'm on stable amd64, and gcc-4.8.2 has barely been un-(hard)masked for ~amd64 only...
FWIW I was also been unable to build any version of dietlibc on hardened, from at least 0.33_preN, 0.33 release, through 0.34_preN. it turns out that selecting no-ssp GCC is enough: # eselect profile show Current /etc/make.profile symlink: hardened/linux/amd64 # gcc-config x86_64-pc-linux-gnu-4.9.2-hardenednossp # . /etc/profile # emerge -v dietlibc And the resulting 'diet' does not segfault instantly. Is there a way for an .ebuild to specify a gcc flavor that it must be compiled with? Is it "approved" to simply run gcc-config, and parse its output, and eerror if we don't like what we see?
*** Bug 538154 has been marked as a duplicate of this bug. ***
Add append-flags $(test-flags -fno-stack-protector) in src_prepare we default to ssp on >=gcc-4.8.3
We disable ssp as default fixed in cvs
