From owner-freebsd-emulation@FreeBSD.ORG Sun Mar 29 18:27:39 2015 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ED16D555; Sun, 29 Mar 2015 18:27:38 +0000 (UTC) Received: from smtp.burggraben.net (smtp.burggraben.net [IPv6:2a01:4f8:140:50a2::3:1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "ns.exwg.net", Issuer "Christoph Moench-Tegeder" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A78C761D; Sun, 29 Mar 2015 18:27:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.burggraben.net (Postfix) with ESMTP id 2B10460008D; Sun, 29 Mar 2015 20:27:35 +0200 (CEST) X-Spam-Scanned: by amavisd-new at exwg.net Received: from smtp.burggraben.net ([127.0.0.1]) by localhost (ns.burggraben.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fp6rFW6zfDVy; Sun, 29 Mar 2015 20:27:34 +0200 (CEST) Received: from elch.exwg.net (dslb-088-066-045-156.088.066.pools.vodafone-ip.de [88.66.45.156]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "elch.exwg.net", Issuer "Christoph Moench-Tegeder" (not verified)) by smtp.burggraben.net (Postfix) with ESMTPS; Sun, 29 Mar 2015 20:27:34 +0200 (CEST) Received: by elch.exwg.net (Postfix, from userid 1000) id 9752C26; Sun, 29 Mar 2015 20:27:33 +0200 (CEST) Date: Sun, 29 Mar 2015 20:27:33 +0200 From: Christoph Moench-Tegeder To: freebsd-emulation@freebsd.org, freebsd-ports@freebsd.org Subject: VirtualBox (sometimes) not starting/hanging after recent openssl updates Message-ID: <20150329182732.GA1415@elch.exwg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 18:27:39 -0000 Hi, for reference, prior reports (not mine): https://lists.freebsd.org/pipermail/freebsd-emulation/2015-March/012381.html https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198952 I got bitten by the very same problem - "NS_ERROR_FACTORY_NOT_REGISTERED" when running VirtualBox "as usual", "VERR_INVALID_POINTER" and "environment corrupt" when using a DEBUG-enabled VirtualBox. As I was pretty sure I had a working VirtualBox 4.3.26 before, I tracked all the changes since the last successful VirtualBox use, and the only "significant" thing was that I upgraded my base system for FreeBSD-SA-15:06.openssl (and the fix for that, so I'm up-to-date with releng/10.1 (r280275). After some time of poking the source and adding more debug statements and asserts (debugging suid code...), I got the following backtrace in my core dump (abbreviated): (gdb) bt #0 0x00000008033257c5 in OPENSSL_ia32_cpuid () from /usr/local/lib/libcrypto.so.8 #1 0x0000000805f88eb9 in ?? () from /lib/libcrypto.so.7 #2 0x0000000805e8f84e in _init () from /lib/libcrypto.so.7 #3 0x00007fffffffc760 in ?? () #4 0x000000080060e6bf in ?? () from /libexec/ld-elf.so.1 #5 0x0000000800612d87 in ?? () from /libexec/ld-elf.so.1 #6 0x000000080060fad3 in ?? () from /libexec/ld-elf.so.1 #7 0x00000000004042d9 in supR3HardenedMainInitRuntime (fFlags=3) Having different versions of a library calling each other (base openssl vs. ports openssl) is most certainly a bad thing. More digging showed that the libcryptos where pulled in by libcurl.so.4. That (curl) in turn links against ports openssl when found (there's even code in the Makefile to stop the build when one tries forcing the use of base openssl), but happily pulls in base openssl via it's dependencies. One instance of the base openssl was found in librtmp and could be solved by recompiling that. The other problem was with the use of "GSSAPI_BASE" (base system GSSAPI) in curl - which is the default, according to a curl-less machine in the corner. In the short run, people affected by the VirtualBox problem should check if /usr/local/lib/virtualbox/VBoxRT.so links against both (base and ports) libcryptos (use ldd) - if so, check libcurl (and if that does not help, the other shared libraries) for libcrypto mixup. In the slightly longer run - how do we want to fix this? I can imagine preventing the use of GSSAPI_BASE when ports openssl is detected - there's similar code already for preventing WITH_OPENSSL_BASE usage when ports openssl is installed. OTOH this will not help in case the "wrong" openssl is pulled in via some other dependency (librtmp in my case). Regards, Christoph -- Spare Space