Weird virtualbox...

kitepilot at kitepilot.com kitepilot at kitepilot.com
Sat Jul 14 09:39:08 MST 2012


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 at kitepilot.com <
> kitepilot at 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 at 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
> **
> <http://it-clowns.com>Safeway.com
> Automation Engineer


More information about the PLUG-discuss mailing list