32bit httpd-2.2.24 built with SSL crashes during startup when run on a freebsd amd64 machine recently updated by building 9.1-STABLE amd64 on a freebsd i386 machine. Stack trace shows: #0 0x282a3c50 in bn_div_words () from /usr/lib32/libcrypto.so.6 #1 0x2829cf7d in BN_div (dv=0x0, rm=0x289432e4, num=0x289432e4, divisor=0x289432f8, ctx=0x289370a0) at /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/bn/bn_div.c:345 The 32bit httpd-2.2.24 works fine on the i386 build machine. Rebuilding the 32bit httpd-2.2.24 without SSL avoids the problem on the amd64 machine. Rebuilding lib32/libcrypto by doing: rm -rf /usr/obj/amd64.amd64/lib32 /usr/obj/amd64.amd64/usr/src/lib32 make TARGET=amd64 TARGET_ARCH=amd64 build32 shows some warning messages: crypto/openssl/crypto/bn/bn_div.c: In function 'BN_div': crypto/openssl/crypto/bn/bn_div.c:304: warning: integer constant is too large for 'long' type crypto/openssl/crypto/bn/bn_div.c:304: warning: large integer implicitly truncated to unsigned type crypto/openssl/crypto/bn/bn_div.c:361: warning: right shift count >= width of type crypto/openssl/crypto/bn/bn_div.c:362: warning: right shift count >= width of type ... Fix: Rebuilding lib32/libcrypto by doing: rm -rf /usr/obj/amd64.amd64/lib32 /usr/obj/amd64.amd64/usr/src/lib32 mkdir -p /usr/obj/amd64.amd64/usr/src/lib32/usr/include/openssl cp /usr/src/secure/lib/libcrypto/opensslconf-i386.h \ /usr/obj/amd64.amd64/usr/src/lib32/usr/include/openssl/opensslconf.h make TARGET=amd64 TARGET_ARCH=amd64 build32 fixes the warning messages and allows the 32bit httpd-2.2.24 built with SSL to work fine on the amd64 machine. It appears that the lib32/libcrypto build is picking up the amd64 opensslconf.h by default. How-To-Repeat: Build httpd-2.2.24 on a 9.1-STABLE i386 machine. Install it on a 9.1-STABLE amd64 machine. Configure SSL. Attempt to start httpd. Notice immediate crash. httpd source code was configured using: ./configure --enable-modules="ssl proxy rewrite" --disable-ipv6
Responsible Changed From-To: freebsd-amd64->freebsd-bugs make this a generic issue.
I've upgraded the machines in question to FreeBSD 10 r269288 and am no longer experiencing the problem.