Latest version... :( No joy... Now, Virtual box works OK from its box or any other of my boxes that I SSH from. That being the case, I have to assume that the problem is with my box's kernel/X/SSH combination. Virtualbox is still running in the remote box, only the output is displayed to another box. That means (to me) that somewhere along the magic-cookie transfer and/or the SSH encryption/decryption, something goes back to the running box that kills the application. That defeats most of my C programming knowledge, which (no arrogance here, I do C/C++ for a living) is more than most people's on this list. Although I haven't done a whole lot of 'X' stuff lately... ET Lisa Kachold writes: > Hi- > > On Sat, Jul 14, 2012 at 8:20 AM, kitepilot@kitepilot.com < > kitepilot@kitepilot.com> wrote: > >> Well, the Gnomes are at work (again) in my box and I could certainly use >> some help to evict them... >> This is what's happening: >> I use: >> 'ssh -fCXY user@remotebox run-something' >> a lot. >> Works every time. >> Or 'mostly' every time... >> Now when I run (ONLY from *MY* box): >> ssh -fCXY turboviking virtualbox >> I get: >> *** glibc detected *** /usr/lib/virtualbox/**VirtualBox: malloc(): memory >> corruption: 0x099c5e48 *** >> And a long trace. >> This is the quick rundown of how it broke: >> My desktop was having hiccups and I decided to replace whatever I had >> (can't remember what) with the latest Xubuntu. >> After that, the problem started. >> This problem, coupled with other issues, led me to scrap Xubuntu and >> install the latest Mint/Mate. >> Problem didn't go away... >> The Xubuntu and Mint installations were fresh from-scratch installs, the >> only thing I preserved was my home directory. >> So the conclusion was evident: there is something in my /home/directory >> causing the problem. >> Nope... >> Created another user, rebooted the box and logged in with the new user. >> Same $#!T... :( >> Now, ANYTHING else that I have fired up works just fine. >> And If I run the exact same instruction from other of my local boxes, it >> works fine too! >> It is ONLY 'vitualbox in my box' that fails. >> But it used to work just fine... >> Now the (unsolvable and incomprehensible to me) question is: >> What could possibly be breaking the whole 'remote SSH run' mechanism (ONLY >> for Virtualbox) in my box, which used to work fine before, and works fine >> from everywhere else. >> Other than sacrificing another goat and burying some transistors and >> garlic wrapped on anti-static paper at midnite with no Moon, I don't know >> what to do... >> I have seen Virtualbox do weird things before when ran it remotely under >> X/SSH, but this blows my (little) mind. :( >> Any ideas? >> Sight... >> ET >> >> That means: > > *** glibc detected *** /usr/lib/virtualbox/VirtualBox >> >> : malloc(): memory corruption: 0x099c5e48 *** > > > The C stack that works fine in some systems can break in others. > > Upgrade your virtualbox. > > Reference: https://forums.virtualbox.org/viewtopic.php?f=2&t=19219 > > For more exact definition (but solution [upgrade] is the same) > > Hardware: > Versions of linux kernel: > Memory Amounts allocated: > -- > (503) 754-4452 Android > (623) 239-3392 Skype > (623) 688-3392 Google Voice > ** > Safeway.com > Automation Engineer --------------------------------------------------- PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us To subscribe, unsubscribe, or to change your mail settings: http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss