The configure script fails with this error: checking errno.h usability... ./configure: line 54780: 16194 Segmentation fault /bin/sh './configure' --prefix=/usr '--prefix=/usr' '--host=i686-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--disable-linuxcaps' '--disable-parse-clocks' '--disable-ipv6' '--enable-debugging' '--with-crypto' '--build=i686-pc-linux-gnu' 'CFLAGS=-O2 -march=i686 -pipe' 'CXXFLAGS=-O2 -march=i686 -pipe' 'LDFLAGS=' 'build_alias=i686-pc-linux-gnu' 'host_alias=i686-pc-linux-gnu' --cache-file=/dev/null --srcdir=. configure: error: /bin/sh './configure' failed for sntp Reproducible: Always Steps to Reproduce: 1. emerge ntp My "emerge --info" is: Portage 2.1.6.4 (hardened/x86/2.6, gcc-3.4.6, glibc-2.6.1-r0, 2.6.25-hardened-r11 i686) ================================================================= System uname: Linux-2.6.25-hardened-r11-i686-Intel-R-_Pentium-R-_D_CPU_2.80GHz-with-glibc2.3.2 Timestamp of tree: Mon, 12 Jan 2009 20:45:01 +0000 app-shells/bash: 3.2_p39 dev-lang/python: 2.5.2-r7 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.63 sys-devel/automake: 1.10.2 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=i686 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -march=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="collision-protect distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch userpriv" GENTOO_MIRRORS="http://mirror.yandex.ru/gentoo-distfiles/ ftp://mirror.yandex.ru/gentoo-distfiles/" LANG="ru_RU.UTF-8" LDFLAGS="" LINGUAS="ru" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://mirror.yandex.ru/gentoo-portage/" USE="berkdb cracklib crypt hardened iconv logrotate midi ncurses nls nptl nptlonly pam pcre perl pic python readline sse sse2 ssl tcpd unicode urandom x86 xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="mouse keyboard evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="ru" USERLAND="GNU" VIDEO_CARDS="apm ark chips cirrus cyrix dummy fbdev glint i128 i740 i810 imstt intel mach64 mga neomagic nsc nv r128 radeon rendition s3 s3virge savage siliconmotion sis sisusb tdfx tga trident tseng v4l vesa vga via vmware voodoo" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS My "gcc --version" is: gcc (GCC) 3.4.6 (Gentoo Hardened 3.4.6-r2 p1.5, ssp-3.4.6-1.0, pie-8.7.10) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Created attachment 178368 [details] build.log
Created attachment 178370 [details] config.log
Created attachment 178371 [details] environment
Very similar error on my machine, on "checking dlfcn.h usability": 1. same kernel: 2.6.25-hardened-r11 2. same gcc: Gentoo Hardened 3.4.6-r2 p1.5, ssp-3.4.6-1.0, pie-8.7.10
I haven't had any trouble compiling ntp-4.2.4-r6 on at least 5 x86 hosts - so I can't reproduce this. However, I have seen some strange bash segfaulting errors during getting gcc 4.3.2 working for hardened (that we have yet to pinpoint). Could you try rebuilding bash and ncurses? Also please paste the output of 'emerge -pv glibc'. Thanks.
Works her to on amd64 gcc 3.4.6-r Hardened and glibc 2.8
It fails for me on x86, even tried it in a fresh chroot (based on phreak's i686 stage3 from 20080110) after emerge -e system. Both fails at checking for dirent.h that defines DIR... ./configure: line 54780: 32544 Segmentation fault /bin/sh './configure' ..... but at different stages. The live system at the first pass, the chroot while configuring sntp. After re-emerging ncurses and bash in the chroot ntp installed. However, trying to immediately re-emerge ntp, it fails with these segfaults a couple of times until it magically gets through again. Of course, after doing all that work in the chroot, ntp (or bash rather) plays nice in the live system, twice, before it fails again... # emerge -pv glibc These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] sys-libs/glibc-2.6.1 USE="hardened nls -debug -gd -glibc-omitfp (-multilib) -profile (-selinux) -vanilla" 0 kB
(In reply to comment #5) > Could you try rebuilding bash and ncurses? Also please paste the > output of 'emerge -pv glibc'. Thanks. > After rebuilding bash and ncurses compiling of ntp fails with the new error (the same to Anders's): checking for dirent.h that defines DIR... /usr/lib/portage/bin/ebuild.sh: line 444: 23662 Segmentation fault "${ECONF_SOURCE}/configure" --prefix=/usr --host=${CHOST} --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib "$@" ${LOCAL_EXTRA_ECONF} b1 ~ # emerge -pv glibc These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] sys-libs/glibc-2.6.1 USE="hardened nls -debug -gd -glibc-omitfp (-multilib) -profile (-selinux) -vanilla" 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB
http://forums.gentoo.org/viewtopic-t-728429.html
I cannot reproduce the problem with ntp here, but I am rather sure that I have exactly the same problem when emerging gcc-4.3.2-r2. It *almost* always fails in the configure of libstdc++-v3 after stage 3 (which unfortunately takes rather long) - but only on amd64, not on x86. The reason definitely is hardened-sources (even if all PAX is disabled; I had no time yet to try with grsec disabled, but with gentoo-sources in the same version there is no crash). I had recompiled bash, glibc, zlib, ncurses, libiconv, gettext, gmp, and mpfr with absolutely safe options (gcc is -hardened, only -march=core2 and -O2). Surprisingly, when compiling gcc manually, it almost never fails. _One_ time I was able to produce it manually reliably, but after the next boot I could not reproduce it again. In this "lucky" moment I found out: 1. It is really bash which crashes when interpreting the configure script. The crash happens when bash has to interpret a rather complex code: Many levels of nested if's and case's - the complete code it has to parse before it can start is several thousand lines long. So I conjecture some sort of (stack?) overflow bug is going on. Just editing the code minimally (inserting some line containing "true" to avoid an immediate "else case .." structure) will often avoid the crash. 2. What is completely weird is that the same crash (under exactly the same conditions) happened when "dash" was used instead of "bash" - I did not verify whether their parsing code originally stems from the same source. 3. I was even able to produce the crash in gdb. But since I had not compiled with debug symbols, I could not produce a useful backtrace. I only found out that it happened somewhere deep in glibc. Other observations: The crash never produces a kernel message. Also strace shows no suspicious actions before the crash. Here are the versions which I use: sys-libs/glibc-2.9_p20081201-r1 sys-devel/gcc-4.3.2-r2 (yes, once I was able to compile it). app-shells/bash-3.2_p48 app-shells/dash-0.5.4.11 sys-kernel/hardened-sources-2.6.27-r3 and -r4 (same error with both) sys-kernel/gentoo-sources-2.6.27-r7 (no error with same config, except grsecurity, of course)
Thanks gents. I am onto this bug and should have it quashed shortly. Please refrain from posting further until requested. I don't need anymore information at this point.
hardened-sources-2.6.25-r13 and hardened-sources-2.6.26-r9 have been added to the tree and should fix this issue. There is not a fixed 2.6.27 release at this time. Please give them a try and report back. Leaving the bug open until: 1. Confirmation of fix. 2. A fixed 2.6.27 release is in the tree. 3. At least one of the fixed releases has been marked stable. Thanks to all who reported and helped to figure out in which release we regressed.
(In reply to comment #10) > 1. It is really bash which crashes when interpreting the configure script. The > crash happens when bash has to interpret a rather complex code: Many levels of > nested if's and case's - the complete code it has to parse before it can start > is several thousand lines long. So I conjecture some sort of (stack?) > overflow bug is going on. Just editing the code minimally (inserting > some line containing "true" to avoid an immediate "else case .." structure) > will often avoid the crash. yes, this problem can trigger only when the kernel automatically expands the userland stack. i made a change in there that would enforce a certain limit even when the expansion is initiated by the kernel itself, not a userland access per se. the fact that it causes a problem points at some deeper issue (it should not happen, i made this change for preventing this exact event as it can be abused in an exploit to extend the userland stack by an arbitrary amount). so for now you can revert that chunk but i'll investigate when i get the time. it would help me a lot if someone could create a minimal testcase to trigger this though.
(In reply to comment #13) > it would help me a lot if someone could create a minimal testcase to trigger this though. actually, the simplest and quickest help would be to get a kernel stack dump when that stack expansion request is denied (to see which kernel code triggers it), could anyone do that?
*** Bug 255617 has been marked as a duplicate of this bug. ***
(In reply to comment #14) > (In reply to comment #13) > > it would help me a lot if someone could create a minimal testcase to trigger this though. > > actually, the simplest and quickest help would be to get a kernel stack dump > when that stack expansion request is denied (to see which kernel code triggers > it), could anyone do that? i've uploaded test9 to my test patch dir that will produce the info i need, now it's up to you to send me your logs ;).
*** Bug 255651 has been marked as a duplicate of this bug. ***
(In reply to comment #12) > hardened-sources-2.6.25-r13 and hardened-sources-2.6.26-r9 have been added to > the tree and should fix this issue. There is not a fixed 2.6.27 release at > this time. Please give them a try and report back. > Ntp compiles successfully with the hardened-sources-2.6.25-r13. Thank you!
sys-kernel/hardened-sources-2.6.27-r5 has been added to the tree with the fix for this bug.
Requirements met, so closing as fixed. Will pursue the bug further with PaX Team. If anyone else wants to help reproduce the bug with pax-2.6.28.1-test9 and provide the PaX Team the requested info feel free to post it here.
Just FYI: Ran into the same Problem. When I manually called ./configure I got "failed for sntp". For me it was enough to recompile openssl. Maybe this info is usefull for some of you, otherwise ignore this comment.
*** Bug 275071 has been marked as a duplicate of this bug. ***
*** Bug 280348 has been marked as a duplicate of this bug. ***
*** Bug 291220 has been marked as a duplicate of this bug. ***
