Date: Tue, 31 Mar 2015 20:43:26 +0200 From: Christoph Moench-Tegeder <cmt@burggraben.net> To: freebsd-emulation@freebsd.org Subject: Re: VirtualBox (sometimes) not starting/hanging after recent openssl updates Message-ID: <20150331184325.GA1503@elch.exwg.net> In-Reply-To: <20150330173027.2207c592@Papi> References: <20150330173027.2207c592@Papi>
next in thread | previous in thread | raw e-mail | index | archive | help
## 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150331184325.GA1503>