## Mario Lobo (l...@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 _______________________________________________ freebsd-emulation@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
