Doing bug 433327, I found that the tests fail with USE="ssl". Test that fails is tls_daemon_options_test Reproducible: Always Steps to Reproduce: 1. emerge net-libs/libmicrohttpd-0.9.21 with USE="ssl" Actual Results: Build fails see attachment. Get a message about some core dump: The following handshake should fail (and print an error message)... curl_easy_perform failed: `SSL connect error' /bin/sh: line 5: 3940 Aborted (core dumped) ${dir}$tst FAIL: tls_daemon_options_test Expected Results: Builds and runs tests without any problems. emerge --info Portage 2.1.11.9 (default/linux/x86/10.0, gcc-4.5.4, glibc-2.15-r2, 3.3.8-gentoo i686) ================================================================= System uname: Linux-3.3.8-gentoo-i686-Intel-R-_Celeron-R-_CPU_2.40GHz-with-gentoo-2.1 Timestamp of tree: Fri, 05 Oct 2012 16:00:01 +0000 distcc 3.1 i686-pc-linux-gnu [enabled] app-shells/bash: 4.2_p37 dev-java/java-config: 2.1.11-r3 dev-lang/python: 2.7.3-r2, 3.2.3 dev-util/cmake: 2.8.7-r5 dev-util/pkgconfig: 0.27.1 sys-apps/baselayout: 2.1-r1 sys-apps/openrc: 0.9.8.4 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.13, 2.68 sys-devel/automake: 1.11.6 sys-devel/binutils: 2.22-r1 sys-devel/gcc: 4.5.4 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82-r3 sys-kernel/linux-headers: 3.4 (virtual/os-headers) sys-libs/glibc: 2.15-r2 Repositories: gentoo x-portage ACCEPT_KEYWORDS="x86" ACCEPT_LICENSE="* -@EULA -dlj-1.1" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium4 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.3/ext-active/ /etc/php/cgi-php5.3/ext-active/ /etc/php/cli-php5.3/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-O2 -march=pentium4 -pipe" DISTDIR="/usr/portage/distfiles" FCFLAGS="-O2 -march=i686 -pipe" FEATURES="assume-digests binpkg-logs collision-protect config-protect-if-modified distcc distlocks ebuild-locks fixlafiles news parallel-fetch parse-eapi-ebuild-head protect-owned sandbox sfperms strict test unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv" FFLAGS="-O2 -march=i686 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="nl" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X accessibility acl alsa apng avahi bash-completion berkdb bluetooth bzip2 cairo cli compat consolekit corefonts cracklib crypt cups curl cxx dbus deprecated devil dri examples expat extensions extras fam fbcon fontconfig fortran fts3 gdbm gdu gif glib gmp gnutls gpm gtk gtk3 gudev hwdb iconv ipv6 java jpeg lapack latex libnotify libssh2 md5sum midi mikmod minizip mmx mod modules mp3 mudflap ncurses nls nptl nsplugin objc ogg opengl openmp pam pcre php pic png policykit postscript pppd python qt3support readline sdl session smpeg sockets sqlite3 sse sse2 ssl startup-notification svg tcpd threads thunar tiff timidity tk tordns truetype udev unicode v4l2 vorbis webdav x86 xcb xml xvfb 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 cgi cgid 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" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="nl" PHP_TARGETS="php5-3" PYTHON_TARGETS="python3_2 python2_7" RUBY_TARGETS="ruby18 ruby19 jruby ree18" USERLAND="GNU" VIDEO_CARDS="vesa intel" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
Created attachment 325804 [details] Build log of the failing build.
> Refusing to run test with OpenSSL. Please install libcurl-gnutls This is probably fallout from upstream's fix to bug 334067.
(In reply to comment #2) > > Refusing to run test with OpenSSL. Please install libcurl-gnutls > > This is probably fallout from upstream's fix to bug 334067. I'm not able to reproduce this with libmicrohttpd-0.9.22 on amd64. Can you test .22 on x86. I don't have native hardware.
Disregard my previous remark. The error here is in the tls_daemon_options_test and not related to the other bug.
(In reply to comment #4) > Disregard my previous remark. The error here is in the > tls_daemon_options_test and not related to the other bug. Okay, I just thought of something. FEATURES="test" pulls in the RDEPEND ssl? ( >=net-misc/curl-7.25.0-r1[ssl] ) but USE="ssl" means that any one of six different backend ssl providers can be pulled in. CURL_SSL="openssl axtls cyassl gnutls nss polarssl" I wonder if tls_daemon_options_test is failing for one of them. I use CURL_SSL="openssl". @Myckel, can you check what CURL_SSL is for you.
(In reply to comment #5) > @Myckel, can you check what CURL_SSL is for you. [ebuild R ] net-misc/curl-7.26.0 USE="ipv6 ssl test threads -ares -idn -kerberos -ldap -ssh -static-libs" CURL_SSL="openssl -axtls -cyassl -gnutls -nss -polarssl" 2,366 kB
Looking at the build log, I think the following is happening: 1) test fails (as expected, SSL connect error) 2) result isn't passed correctly to the validating section (segfault) 3) validating section finds the segfault en says the test fails. So, where is it segfaulting?
Doing some tests: 1) On a ~x86 chroot on a different system, tests are successful. 2) Problem exists in version 0.9.22 on the system that I use for stabilization.
(In reply to comment #7) > Looking at the build log, I think the following is happening: > > 1) test fails (as expected, SSL connect error) > 2) result isn't passed correctly to the validating section (segfault) > 3) validating section finds the segfault en says the test fails. > > So, where is it segfaulting? 1) strace until you hit the seg fault and post that. 2) if you are comfortable with gdb, run until segfault and give me a bt 3) post anything different about the two systems I've tested in an x86 vm, no problem, so I'm thinking invalid, but you have some issue so let's narrow it and make sure it isn't something that is going to pop up again in libmicrohttpd
Ok, in strace it seems that the bug does not surface (all tests are successful). GDB gave the following trace (I hope I did it right): Program received signal SIGABRT, Aborted. 0xb7fe0424 in ?? () (gdb) bt #0 0xb7fe0424 in ?? () #1 0xb7ce7d73 in abort () from /lib/libc.so.6 #2 0xb7fd2aef in mhd_panic_std (cls=0x0, file=0xb7fdbe6c "daemon.c", line=2586, reason=0x0) at daemon.c:104 #3 0xb7fd6228 in close_all_connections (daemon=0x806a3b0) at daemon.c:2586 #4 0xb7fd65aa in MHD_stop_daemon (daemon=0x806a3b0) at daemon.c:2682 #5 0x08049e6e in teardown_testcase (d=0x806a3b0) at tls_test_common.c:380 #6 0x0804a0d0 in test_wrap (test_name=0x804a819 "TLS1.0 vs SSL3", test_function=0x80490c8 <test_unmatching_ssl_version>, cls=0x0, daemon_flags=7, cipher_suite=0x804a70b "AES256-SHA", proto_version=3) at tls_test_common.c:477 #7 0x080493e9 in main (argc=1, argv=0xbfffefd4) at tls_daemon_options_test.c:171 Any idea what to recompile to get #0? glibc? The only difference between the systems that I can think about is the CPU optimization (-march=pentium4 against -march=athon-xp), for the rest they are mostly similar.
Looking into it, close_all_connection gets stuck at collecting threads (as the comment at the code block says), calling mhd_panic_std, which calls abort. Why? System too slow?
(In reply to comment #11) > Looking into it, close_all_connection gets stuck at collecting threads (as > the comment at the code block says), calling mhd_panic_std, which calls > abort. > > Why? System too slow? I'm sorry Myckel, I can't reproduce this even on native x86 --- well not quite. A 64-bit processor with a purely 32-bit userland. You did the gdb right and your interpretation is correct but I'm not sure what it is about your system that's doing this. Let's leave this bug open for now and see if anyone hits the same issue. I could be a different upgrade path? Not sure.
(In reply to comment #12) > Let's leave this bug open for now and see if anyone hits the same issue. Fine with me.
(In reply to comment #13) > (In reply to comment #12) > > Let's leave this bug open for now and see if anyone hits the same issue. > > Fine with me. I don't know if you're still interested, but I just added 0.9.24 to the tree. All the tests worked for me. Would you test again and see if this is still an issue?
(In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #12) > > > Let's leave this bug open for now and see if anyone hits the same issue. > > > > Fine with me. > > I don't know if you're still interested, but I just added 0.9.24 to the > tree. All the tests worked for me. Would you test again and see if this is > still an issue? Sorry for the slow reply. I'm still able to reproduce the bug in 0.9.24 and 0.9.26 (latest in tree).
(In reply to comment #15) > (In reply to comment #14) > > (In reply to comment #13) > > > (In reply to comment #12) > > > > Let's leave this bug open for now and see if anyone hits the same issue. > > > > > > Fine with me. > > > > I don't know if you're still interested, but I just added 0.9.24 to the > > tree. All the tests worked for me. Would you test again and see if this is > > still an issue? > > Sorry for the slow reply. > I'm still able to reproduce the bug in 0.9.24 and 0.9.26 (latest in tree). Can you do an strace and not a backtrace. Like this strace -f -o libmicrohttpd.log emerge libmicrohttpd plus any other environment variables. It will be very long, but if you know what to look for, give me just the failing test's trace. I'm still wondering if something else is broken on your system, so can you reproduce this on *any* other system. I've been using x86 chroots.
(In reply to comment #16) > I'm still wondering if something else is broken on your system, so can you > reproduce this on *any* other system. I've been using x86 chroots. On a VIA EPIA2 system I can't reproduce this. Seems something is broken on the P4 system. I'll have a further look into it to fix it. For this reason I close this bug.
