From owner-freebsd-emulation@FreeBSD.ORG Tue Mar 31 18:43:30 2015 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6C7F44B for ; Tue, 31 Mar 2015 18:43:30 +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 8FE55215 for ; Tue, 31 Mar 2015 18:43:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.burggraben.net (Postfix) with ESMTP id ADB9760008D for ; Tue, 31 Mar 2015 20:43:27 +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 B-BzgGUXIyAV for ; Tue, 31 Mar 2015 20:43:26 +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 for ; Tue, 31 Mar 2015 20:43:26 +0200 (CEST) Received: by elch.exwg.net (Postfix, from userid 1000) id 3C4E06A; Tue, 31 Mar 2015 20:43:26 +0200 (CEST) Date: Tue, 31 Mar 2015 20:43:26 +0200 From: Christoph Moench-Tegeder To: freebsd-emulation@freebsd.org Subject: Re: VirtualBox (sometimes) not starting/hanging after recent openssl updates Message-ID: <20150331184325.GA1503@elch.exwg.net> References: <20150330173027.2207c592@Papi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150330173027.2207c592@Papi> 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: Tue, 31 Mar 2015 18:43:30 -0000 ## Mario Lobo (lobo@bsd.com.br): > /usr/local/lib/virtualbox/VBoxRT.so: > (snip) > libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x8026a7000) > libcrypto.so.7 => /lib/libcrypto.so.7 (0x80431d000) > libcrypt.so.5 => /lib/libcrypt.so.5 (0x804fee000) > > and mine is fine too! Perhaps you're lucky. Going slightly deeper into the gory details: virtualbox uses the environment (VBOX_XPCOM_HOME) to "find itself". Also, here and in some reports we had the "environment corrupt" message, that's from libc, indicating that an entry in the environment is malformed (not NAME=VALUE) - this should (can?) not happen when you use the environment "normally". I could get around that message (and get virtualbox working) by making the environment smaller, that is, removing entries (one does not really need TERMCAP or LC_* for starting virtualbox...). I pinpointed the location of my problem by peppering the virtualbox code with assert()s on parts of the environment... Once I had removed the second (the base system) libcrypto, the environment (and surrounding memory, as far as I can tell) does not get corrupted anymore, so I claim causality on the base of correlation :) (it's completely plausible that data structure mismatch between the two versions of openssl may cause out-of-bounds memory access and related trouble). Regards, Christoph -- Spare Space