apt-get update This is possibly a known malloc issue with glibc for your chipset. Research requires full backtrace, versions, firmware and chipset versions. # dmidecode A post to the mint support might net more info although I would do exhaustive reasearch on the error x-referenced with your hardware/OS. On 14 Jul 2012 09:39, "kitepilot@kitepilot.com" wrote: > 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 >