I just tried several times to emerge Apache 2.0.49-r1, resulting in a segfaulting apache2 binary. Going back to a previous ebuild had the same result. Changing CFLAGS didn't seem to be the issue, however, it seems that Apache was configured to use LDAP (which was not anymore in my USE flags, but a while ago it has been for a short period of time). I've had to change my USE flags to include -ldap to forcefully prevent it from using LDAP functionality and hence to prevent getting a segfaulting binary. Reproducible: Always Steps to Reproduce: 1. emerge apache (logic dictates one should also have LDAP already installed?) 2. Try to run it, it segfaults 3. Rebuild with -ldap in the USE-flags, and it works. Expected Results: It should have build a non-segfaulting binary right away. :) OpenLDAP 2.1.26 is currently still installed on my system, although not yet in active usage by me.
I can't reproduce the bug, can you give the result of emerge info please ? maybe a log of strace could be usefull too.
Created attachment 31402 [details] strace output This is the strace output of my segfaulting Apache2 binary, built with LDAP support.
Here's the output of 'emerge info': Portage 2.0.50-r6 (default-x86-2004.0, gcc-3.3.2, glibc-2.3.2-r9, 2.4.25-gentoo) ================================================================= System uname: 2.4.25-gentoo i686 Intel(R) Pentium(R) 4 CPU 1.90GHz Gentoo Base System version 1.4.10 distcc 2.13 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.58-r1 Automake: sys-devel/automake-1.8.3 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=pentium4 -O2 -pipe -fomit-frame-pointer -fstack-protector" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /etc/tomcat /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium4 -O2 -pipe -fomit-frame-pointer -fstack-protector" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://gentoo.tiscali.nl/gentoo/ http://ftp6.uni-erlangen.de/pub/mirrors/gentoo ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo http://ftp.snt.utwente.nl/pub/os/linux/gentoo http://ftp.easynet.nl/mirror/gentoo/ http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/ http://ftp.gentoo.skynet.be/pub/gentoo/ http://www.mirror.ac.uk/sites/www.ibiblio.org/gentoo/ http://gentoo.oregonstate.edu/ http://www.ibiblio.org/pub/Linux/distributions/gentoo ftp://sunsite.ualberta.ca/pub/unix/Linux/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="3dfx X Xaw3d aalib acpi acpi4linux alsa apache2 apm arts avi berkdb cdr crypt cups curl dga directfb dnd dvd encode esd fbcon flash foomaticdb gatos gd gd-external gdbm gif gnome gphoto2 gpm gtk gtk2 imap imlib innodb ipv6 java jpeg kde kerberos ldap libg++ libwww linguas_nl mad mbox mdb mikmod motif mozilla mpeg mysql nas ncurses nls odbc oggvorbis opengl oss pam pdflib perl pic png python qt quicktime radeon readline samba sasl sdk sdl slang spell sse ssl svga tcltk tcpd tiff truetype usagi usb v4l vim-with-x wmf x86 xml xml2 xmms xosd xv xvid zlib" It was interesting to me to see LDAP in between those USE flags. Doing some research it seems to have included it from /etc/make.profiles/use.default because the LDAP package was installed. So to me that in each case explains why Apache2 was building with LDAP support although it was not in my USE flags. It still remains however that when build against LDAP the binary segfaults on my system. The strace output has been added as well as attachment.
I have not been able to reproduce it either. Could you do the following: ldd /usr/sbin/apache2 Thanks
ldd /var/tmp/portage/apache-2.0.49-r1/image/usr/sbin/apache2 libz.so.1 => /usr/lib/libz.so.1 (0x48f8a000) libaprutil-0.so.0 => /usr/lib/libaprutil-0.so.0 (0x4002f000) libldap.so.2 => /usr/lib/libldap.so.2 (0x40044000) libbind.so.2 => /usr/lib/libbind.so.2 (0x40074000) libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x49bdb000) libresolv.so.2 => /lib/libresolv.so.2 (0x400bc000) libssl.so.0.9.7 => /usr/lib/libssl.so.0.9.7 (0x400cf000) libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0x400ff000) liblber.so.2 => /usr/lib/liblber.so.2 (0x401f8000) libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x49d12000) libdb-4.1.so => /usr/lib/libdb-4.1.so (0x40204000) libexpat.so.0 => /usr/lib/libexpat.so.0 (0x491b5000) libapr-0.so.0 => /usr/lib/libapr-0.so.0 (0x402c6000) librt.so.1 => /lib/librt.so.1 (0x402e6000) libm.so.6 => /lib/libm.so.6 (0x402f9000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x4031a000) libnsl.so.1 => /lib/libnsl.so.1 (0x40347000) libpthread.so.0 => /lib/libpthread.so.0 (0x4035c000) libdl.so.2 => /lib/libdl.so.2 (0x403ad000) libc.so.6 => /lib/libc.so.6 (0x403b0000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Which version of berkely db are you using?
Berkeley DB 4.1.25 Output of 'etcat -v db': * sys-libs/db : [ I] 1.85-r1 (1) [ ] 3.2.9-r7 (3) [ I] 3.2.9-r9 (3) [M~ ] 3.2.9-r10 (3) [M~ ] 3.3.11 (3) [ I] 4.0.14-r2 (4) [ ] 4.0.14-r3 (4) [ I] 4.1.25_p1-r3 (4.1) [M~ ] 4.2.52_p1 (4.2) [M~ ] 4.2.52_p2 (4.2)
Minati, Which db version are you using?
Also can you go to your /usr/include/db.h and grep for the following: DB_VERSION_MAJOR DB_VERSION_MINOR DB_VERSION_PATCH Also I have noticed that you have db-4.0 installed as well. Can you do a ldd of /usr/lib/openldap/slapd. Thanks
could we please also have the output of 'ls -l /usr/include/db* /usr/lib/libdb*'
------------------------------------------------------ From '/usr/include/db.h': ------------------------------------------------------ /* * Berkeley DB version information. */ #define DB_VERSION_MAJOR 4 #define DB_VERSION_MINOR 1 #define DB_VERSION_PATCH 25 #define DB_VERSION_STRING "Sleepycat Software: Berkeley DB 4.1.25: (December 19, 2002)" ------------------------------------------------------ Output of 'ldd /usr/lib/openldap/slapd': ------------------------------------------------------ libldap_r.so.2 => /usr/lib/libldap_r.so.2 (0x4002f000) liblber.so.2 => /usr/lib/liblber.so.2 (0x40063000) libdb-4.1.so => /usr/lib/libdb-4.1.so (0x4006f000) libperl.so.1 => /usr/lib/libperl.so.1 (0x40130000) libm.so.6 => /lib/libm.so.6 (0x4022a000) libutil.so.1 => /lib/libutil.so.1 (0x4024b000) libiodbc.so.2 => /usr/lib/libiodbc.so.2 (0x4024f000) libiodbcinst.so.2 => /usr/lib/libiodbcinst.so.2 (0x40292000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x4029d000) libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x49bdb000) libresolv.so.2 => /lib/libresolv.so.2 (0x402ca000) libssl.so.0.9.7 => /usr/lib/libssl.so.0.9.7 (0x402dc000) libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0x4030d000) libbind.so.2 => /usr/lib/libbind.so.2 (0x40406000) libnsl.so.1 => /lib/libnsl.so.1 (0x4044e000) libpthread.so.0 => /lib/libpthread.so.0 (0x40463000) libltdl.so.3 => /usr/lib/libltdl.so.3 (0x404b3000) libdl.so.2 => /lib/libdl.so.2 (0x404ba000) libwrap.so.0 => /lib/libwrap.so.0 (0x404be000) libc.so.6 => /lib/libc.so.6 (0x404c7000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) ------------------------------------------------------ Output of 'ls -l /usr/include/db* /usr/lib/libdb*': ------------------------------------------------------ lrwxr-xr-x 1 root root 10 Mar 7 01:02 /usr/include/db.h -> db4.1/db.h lrwxr-xr-x 1 root root 14 Mar 7 01:02 /usr/include/db_185.h -> db4.1/db_185.h lrwxr-xr-x 1 root root 11 Mar 7 01:02 /usr/lib/libdb-1.so -> libdb1.so.2 -rw-r--r-- 1 root root 745438 Sep 3 2003 /usr/lib/libdb-3.2.a -rw-r--r-- 1 root root 629 Sep 3 2003 /usr/lib/libdb-3.2.la -rwxr-xr-x 1 root root 593694 Sep 3 2003 /usr/lib/libdb-3.2.so lrwxr-xr-x 1 root root 12 Mar 7 01:02 /usr/lib/libdb-3.so -> libdb-3.2.so -r--r--r-- 1 root root 850264 Aug 23 2003 /usr/lib/libdb-4.0.a -r--r--r-- 1 root root 703 Aug 23 2003 /usr/lib/libdb-4.0.la -r-xr-xr-x 1 root root 696598 Aug 23 2003 /usr/lib/libdb-4.0.so -rw-r--r-- 1 root root 1081704 Mar 7 01:02 /usr/lib/libdb-4.1.a -rw-r--r-- 1 root root 703 Mar 7 01:02 /usr/lib/libdb-4.1.la -rwxr-xr-x 1 root root 798668 Mar 7 01:02 /usr/lib/libdb-4.1.so lrwxr-xr-x 1 root root 11 Mar 7 01:02 /usr/lib/libdb.a -> libdb-4.1.a lrwxr-xr-x 1 root root 12 Mar 7 01:02 /usr/lib/libdb.so -> libdb-4.1.so lrwxr-xr-x 1 root root 11 Mar 7 01:02 /usr/lib/libdb.so.2 -> libdb1.so.2 lrwxr-xr-x 1 root root 12 Mar 7 01:02 /usr/lib/libdb.so.3 -> libdb-3.2.so -rw-r--r-- 1 root root 851686 Apr 25 2003 /usr/lib/libdb1.a lrwxr-xr-x 1 root root 11 Mar 7 01:02 /usr/lib/libdb1.so -> libdb1.so.2 -rwxr-xr-x 1 root root 64377 Apr 25 2003 /usr/lib/libdb1.so.2 -rw-r--r-- 1 root root 815554 Sep 3 2003 /usr/lib/libdb_cxx-3.2.a -rw-r--r-- 1 root root 649 Sep 3 2003 /usr/lib/libdb_cxx-3.2.la -rwxr-xr-x 1 root root 652713 Sep 3 2003 /usr/lib/libdb_cxx-3.2.so lrwxr-xr-x 1 root root 16 Mar 7 01:02 /usr/lib/libdb_cxx-3.so -> libdb_cxx-3.2.so -r--r--r-- 1 root root 938704 Aug 23 2003 /usr/lib/libdb_cxx-4.0.a -r--r--r-- 1 root root 731 Aug 23 2003 /usr/lib/libdb_cxx-4.0.la -r-xr-xr-x 1 root root 772837 Aug 23 2003 /usr/lib/libdb_cxx-4.0.so -rw-r--r-- 1 root root 1176790 Mar 7 01:02 /usr/lib/libdb_cxx-4.1.a -rw-r--r-- 1 root root 731 Mar 7 01:02 /usr/lib/libdb_cxx-4.1.la -rwxr-xr-x 1 root root 864680 Mar 7 01:02 /usr/lib/libdb_cxx-4.1.so lrwxr-xr-x 1 root root 15 Mar 7 01:02 /usr/lib/libdb_cxx.a -> libdb_cxx-4.1.a lrwxr-xr-x 1 root root 16 Mar 7 01:02 /usr/lib/libdb_cxx.so -> libdb_cxx-4.1.so lrwxr-xr-x 1 root root 16 Mar 7 01:02 /usr/lib/libdb_cxx.so.3 -> libdb_cxx-3.2.so -r--r--r-- 1 root root 962088 Aug 23 2003 /usr/lib/libdb_java-4.0.a -r--r--r-- 1 root root 738 Aug 23 2003 /usr/lib/libdb_java-4.0.la -r-xr-xr-x 1 root root 786469 Aug 23 2003 /usr/lib/libdb_java-4.0.so -rw-r--r-- 1 root root 1195894 Mar 7 01:02 /usr/lib/libdb_java-4.1.a -rw-r--r-- 1 root root 738 Mar 7 01:02 /usr/lib/libdb_java-4.1.la -rwxr-xr-x 1 root root 884832 Mar 7 01:02 /usr/lib/libdb_java-4.1.so lrwxr-xr-x 1 root root 16 Mar 7 01:02 /usr/lib/libdb_java.a -> libdb_java-4.1.a lrwxr-xr-x 1 root root 17 Mar 7 01:02 /usr/lib/libdb_java.so -> libdb_java-4.1.so -r--r--r-- 1 root root 992360 Aug 23 2003 /usr/lib/libdb_tcl-4.0.a -r--r--r-- 1 root root 731 Aug 23 2003 /usr/lib/libdb_tcl-4.0.la -r-xr-xr-x 1 root root 809933 Aug 23 2003 /usr/lib/libdb_tcl-4.0.so -rw-r--r-- 1 root root 1177256 Mar 7 01:02 /usr/lib/libdb_tcl-4.1.a -rw-r--r-- 1 root root 731 Mar 7 01:02 /usr/lib/libdb_tcl-4.1.la -rwxr-xr-x 1 root root 864924 Mar 7 01:02 /usr/lib/libdb_tcl-4.1.so lrwxr-xr-x 1 root root 15 Mar 7 01:02 /usr/lib/libdb_tcl.a -> libdb_tcl-4.1.a lrwxr-xr-x 1 root root 16 Mar 7 01:02 /usr/lib/libdb_tcl.so -> libdb_tcl-4.1.so /usr/include/db1: total 24 -rw-r--r-- 1 root root 8298 Apr 25 2003 db.h -rw-r--r-- 1 root root 4456 Apr 25 2003 mpool.h -rw-r--r-- 1 root root 2881 Apr 25 2003 ndbm.h /usr/include/db3: total 84 -r--r--r-- 1 root root 51043 Sep 3 2003 db.h -r--r--r-- 1 root root 5657 Sep 3 2003 db_185.h -r--r--r-- 1 root root 19263 Sep 3 2003 db_cxx.h /usr/include/db4: total 116 -r--r--r-- 1 root root 1209 Aug 23 2003 cxx_common.h -r--r--r-- 1 root root 2129 Aug 23 2003 cxx_except.h -r--r--r-- 1 root root 70362 Aug 23 2003 db.h -r--r--r-- 1 root root 5903 Aug 23 2003 db_185.h -r--r--r-- 1 root root 22225 Aug 23 2003 db_cxx.h /usr/include/db4.1: total 128 -r--r--r-- 1 root root 1212 Mar 7 01:02 cxx_common.h -r--r--r-- 1 root root 3967 Mar 7 01:02 cxx_except.h -r--r--r-- 1 root root 78588 Mar 7 01:02 db.h -r--r--r-- 1 root root 6210 Mar 7 01:02 db_185.h -r--r--r-- 1 root root 25120 Mar 7 01:02 db_cxx.h
chuck , I installed the same version as mentionned above : 3.2.9-r10,3.3.11,4.2.52_p1,4.2.52_p2 I still can't reproduce the bug.
Looks like this may be the same as #39667.
Well there was 38 bugs related to apache2 and LDAP including 4 bugs causing segfaults. When the bugs have commited to cvs upstream then we will be intergrating the bug fixes into -r2.
I have added a patch to -r1 that might fix the problem. Please test., if its still not working correctly. Please follow the debugging instructions on the following: http://httpd.apache.org/dev/debugging.html Thanks chuck
Hi, thanks for your help so far already. And this does indeed seem like it might be the same issue as #39667. So my apologies for having reported it again. I must have missed it during my search prior to reporting. Chuck, thanks for the patch, I've done emerge sync and I see the files being from today and a LDAP patch being present. However, unfortunately it still crashes. I've tried both the -r1 and -r2 ebuilds. Using the GDB instructions at the Apache website I get the following: GNU gdb 6.0 Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) b ap_process_request Breakpoint 1 at 0x80656b5 (gdb) run -X -d /usr/lib/apache2 Starting program: /var/tmp/portage/apache-2.0.49-r1/work/httpd-2.0.49/.libs/apache2 -X -d /usr/lib/apache2 [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 4301)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 4301)] 0x4042951c in memcpy () from /lib/libc.so.6
what if you try this? USE="threads" emerge apache. chuck
Ive also added support for compiling a static LDAP in 2.0.49-r2. Please test by using the following USE FLAGS: USE="LDAP static" emerge apache-2.0.49-r2. Thanks chuck
I've quickly tried both suggestions: USE="threads" emerge apache fails during configuration: Configuring Apache Portable Runtime library ... checking for APR... reconfig updating cache /var/tmp/portage/apache-2.0.49-r1/work/httpd-2.0.49/config.cache configuring package in srclib/apr now configure: WARNING: If you wanted to set the --build type, don't use --host. If a cross compiler is detected then cross compile mode will be used. configure: loading cache /var/tmp/portage/apache-2.0.49-r1/work/httpd-2.0.49/config.cache checking build system type... (cached) i686-pc-linux-gnu checking host system type... (cached) i686-pc-linux-gnu checking target system type... (cached) i686-pc-linux-gnu Configuring APR library Platform: i686-pc-linux-gnu checking for working mkdir -p... (cached) yes APR Version: 0.9.5 checking for chosen layout... apr checking for i686-pc-linux-gnu-gcc... gcc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. configure failed for srclib/apr !!! ERROR: net-www/apache-2.0.49-r1 failed. !!! Function src_compile, Line 177, Exitcode 1 !!! bad ./configure please submit bug report to bugs.gentoo.org. Include your config.layout. USE="LDAP static" emerge apache-2.0.49-r2 results in Apache still segfaulting. Sidenote: I noticed a typo in the Apache-2.0.49 -r1 / -r2 ebuilds, it's informing a 'DB verison detected' instead of a version. :)
Can you add the following to your apache.conf, restart and have a look at the error_logs. LogLevel debug More information can be found at http://httpd.apache.org/docs-2.0/mod/core.html#loglevel Thanks chuck
No luck with the LogLevel, it doesn't seem to log a thing. I did do a ltrace however. The last lines seem to suggest it crashes when calling apr_sockaddr_info_get(). It still doesn't give me an idea right now about what is wrong, but maybe it might be usefull information. :) apr_file_open_stderr(0x080b6db8, 0x080a8a78, 108, 0, 0x402d619c) = 0 apr_palloc(0x080a8a78, 16, 108, 0, 0x402d619c) = 0x080b6e50 apr_sockaddr_info_get(0x080b6e54, 0, 2, 0, 0 <unfinished ...> --- SIGSEGV (Segmentation fault) --- +++ killed by SIGSEGV +++
No progress..Please submit a bug upstream. http://issues.apache.org. Please attach bug # here. Thanks
Reported as Issue #29572 at http://issues.apache.org/bugzilla/show_bug.cgi?id=29572
Same solution as Gentoo bug #39667: Having OpenLDAP not being compiled against libbind, but against libresolv instead stopped the segfaulting of Apache. This (old) OpenLDAP issue might be related: http://www.openldap.org/its/?findid=1304 The patch posted there apparently got outdated since it does not cleanly apply anymore, however, manually patching the configuration script and switching the order of lib_bind and lib_resolv had my OpenLDAP built against libresolv instead of libbind. Perhaps the Gentoo OpenLDAP ebuild should include such a patch to prevent this problem from surfacing again (although the latest unmasked Bind ebuild does not include --enable-libbind anymore, which is a solution as well).
Is this still an issue ?
