Virtualbox 1.6.4 segfault when displayed via ssh/X11forward => Fixed in 2.0.4

[Jonathan Woithe]

During my testing of Virtualbox 1.6.4 (binary edition) I have noticed a problem when connecting to the virtualbox host via ssh with X11 forwarding active. Let's say machine "Ahost" is where I'm sitting and "Bhost" is the machine with virtualbox installed. On Ahost I do

ssh -Y Bhost

which gets me a prompt on Bhost. DISPLAY is set to "localhost:11.0" which is the proxy set up by ssh.

I then start Virtualbox which runs as expected. I select the desired VM and "start" it. At this point it *might* run - if not, the VM status becomes "Aborted" and dmesg reports

VirtualBox[23317]: segfault at 0 ip 00000000 sp bfb37bac error 4 in VirtualBox[8048000+20f000]

If the VM starts then everything runs apparently without trouble until I do a shutdown/poweroff of the VM. The guest OS shuts down normally and the window disappears, but the VM status is again reported as "Aborted". This time dmesg reports

VirtualBox[23511]: segfault at b28db1c8 ip b5d67440 sp bfdd21d0 error 4 in libSDL-1.2.so.0.11.2[b5d4f000+66000]

None of these segfaults occur if I run Virtualbox directly from an xsession running on Bhost (DISPLAY set to ":0.0"). However, curiously enough if I do

xhost +
ssh Bhost

on Ahost, and then do

export DISPLAY=Ahost:0.0
Virtualbox

in the resulting shell running on Bhost the segfaults do not occur and everything seems to perform as expected. Finally, doing

ssh -Y Bhost

*on Bhost* and then running "Virtualbox" gives rise to the problems.

So in other words, it is not the remote display itself which causes the problem, but simply the act of displaying on an X display created by ssh's X11 forwarding feature.

Has anyone else seen this? Are there any known fixes? I'm willing to run tests to assist tracking this down.

Both Ahost and Bhost are running Slackware 12.1 with a 2.6.26 kernel.

Regards

jonathan

[Frank Mehnert]

Jonathan, thanks for this report. So far we were not able to reproduce this problem. How often do you does the SEGFAULT occur? Please could you attach your VBox.log file of such a session (I need the configuration settings). And which package did you use, I assume the Linux .run package?

[Frank Mehnert]

Ah, and which SDL version is installed on your system?

[Russell Yanofsky]

I have this exact problem with Virtualbox 1.6.4 on my gentoo amd64 system. I attached my log files. My version of SDL is 1.2.11.

[Jonathan Woithe]

Frank: if the segfault occurs during VM startup the VBox.log file isn't even created so I can't attach the log from that case. As to how often it occurs, the abort on VM start seems to occur more often than not: just now I had to hit "Start" 5 times before the VM actually started (on the previous 4 attempts it just "Aborted" straight away). The crash on exit has occurred every time the VM guest OS is shut down. In other words, if the VM survives the startup an Abort is guaranteed when the guest OS is shut down. I should note however that the shutdown of the guest OS appears to complete.

To shutdown the guest in my case I'm just doing Start-Shutdown.

I shall attach the VBox.log which was created on VM shutdown for your reference.

SDL is version 1.2.13.

[Jonathan Woithe]

Log generated when the guest OS has been shut down

[Jonathan Woithe]

Frank: the package I am using is indeed the .run package as you guessed. VirtualBox-1.6.4-Linux_x86.run to be precise. For various reasons, /opt on the system concerned is a symlink to /usr/opt but this shouldn't cause a problem. Starting from a normal shell I run virtualbox using

cd /usr/opt/VirtualBox-1.6.4
setenv LD_LIBRARY_PATH `pwd`
./VirtualBox

[Jonathan Woithe]

Frank: any further news or progress?

[Frank Mehnert]

Not really. Sometimes I'm able to reproduce this problem but it seems that a really slow internet connection is required which I currently don't have :) Any good idea to simulate this? Even calling ssh -Y localhost several times is not sufficient.

Apart from this it is most likely that the problem comes from mixing SDL and Qt. Starting with VirtualBox 2.0.0 you can try to start the VM with

VirtualBox -rmode image -startvm VM_NAME

The image mode uses the builtin Qt graphics mode and don't depends on SDL. Several problems vanish when using this mode, probably these SEGFAULTS as well.

[Jonathan Woithe]

Referring back to my initial post, both the host I was displaying on (Ahost) and the host running Virtualbox (Bhost) were connected through a gigabit network switch and both machines had gigabit adapters. It's hard to see how a "really slow internet connection" comes close to this setup. You mention that "ssh -Y localhost" doesn't recreate the problems. Have you tried substituting the machine's FQDN in place of "localhost"? In my case using the machine's name did trigger the problem. I can't recall whether I tried "localhost", but I suspect I didn't since in my environment "localhost" is ambiguous and creates host signature problems (I log on to a number of machines using the same home directory, so at any given time "localhost" can refer to several different machines).

Beyond what's mentioned in my original post I don't have anything to add unfortunately. All I can say is that with the setup as described it really wasn't hard to trigger the fault. In the meantime I will test the image mode of 2.0.0 and see what happens.

[Frank Mehnert]

I wrote that I'm able to reproduce the problem but only very seldom, not suitable for debugging. And yes, I used the FQDN as well.

[Jonathan Woithe]

That's a puzzle then - in my case the problem triggers on more than 75% of occasions. I assume you've also tried with separate hosts as I did (in addition to trying the Ahost==Bhost situation). Which Linux distribution were you running Virtualbox on? I'm wondering whether there's some subtle interaction going on between a particular version of a system library or something.

I will keep thinking to see if I can come up with any other suggestions. At the same time I will check 2.0.0 out to see what the situation is with that.

[Till Mossakowski]

I can reproduce the problem with an Ubuntu Hardy host and Windows XP guest, using virtualbox-2.0_2.0.2-36488%5fUbuntu%5fhardy_i386.deb

[Frank Mehnert]

Did anyone of your tested the image mode (see my comment from 09/09/08)?

[Jonathan Woithe]

Sorry for the delay in responding - I've had a lot of things going on lately.

Firstly, I can confirm that starting the machine from the VirtualBox GUI under 2.0.0 still exhibits the same problems as I had before. I note that another person has confirmed this as well.

I just tried the image mode as described in your comment on 9 Sept. The result was another segfault. The VM window appeared, appeared to get as far as doing some mode setting, and then Virtualbox died. The final lines of log output were as follows.

00:00:17.653 Changing the VM state from 'CREATED' to 'RUNNING'.
00:00:17.658 Guest Log: BIOS: VirtualBox 2.0.0
00:00:17.658 PIT: mode=2 count=0x10000 (65536) - 18.20 Hz (ch=0)
00:00:17.670 PIIX3 ATA: Ctl#0: RESET, DevSel=0 AIOIf=0 CmdIf0=0x00 (-1 usec ago) CmdIf1=0x00 (-1 usec ago)
00:00:17.670 PIIX3 ATA: Ctl#0: finished processing RESET
00:00:17.670 Guest Log: BIOS: ata0-0: PCHS=16383/16/63 LCHS=1024/255/63
00:00:17.670 PIIX3 ATA: Ctl#1: RESET, DevSel=0 AIOIf=0 CmdIf0=0x00 (-1 usec ago) CmdIf1=0x00 (-1 usec ago)
00:00:17.670 PIIX3 ATA: Ctl#1: finished processing RESET
00:00:17.671 PIT: mode=2 count=0x48d3 (18643) - 64.00 Hz (ch=0)
00:00:17.673 Display::handleDisplayResize(): uScreenId = 0, pvVRAM=b323d000 w=640 h=480 bpp=32 cbLine=0xA00

So, no indication of anything going wrong in there.

Finally, using "xhost +" on my display machine and setting DISPLAY on the VirtualBox host to point directly to my display did allow VirtualBox to start and seemingly behave normally. However, after the guest OS was shut down I got another segfault from Virtualbox. This didn't happen when I tried the same thing under 1.6.4, but maybe I was just lucky. In any case the log file gives no indication of what the problem might be, as shown from the following lines from the very end of the log.

00:07:23.920 ************** End of Guest state at power off ***************
00:07:23.920 Changing the VM state from 'RUNNING' to 'OFF'.
00:07:23.921 Console::powerDown(): a request to power off the VM has been issued (mMachineState=8, InUninit=0)
00:07:23.921 SharedFolders host service: disconnected, u32ClientID = 1
00:07:23.921 vboxClipboardDestroy: shutting down host clipboard
00:07:24.023 vboxClipboardThread: clipboard thread terminated successfully with return code VINF_SUCCESS
00:07:25.094 Changing the VM state from 'OFF' to 'DESTROYING'.
00:07:25.094 ************************* Statistics *************************
00:07:25.094 /Devices/ATA0/Unit0/AtapiDMA            0 times
:
00:07:25.094 /TM/VirtualSync/CurrentOffset    27888033 ns
00:07:25.094 ********************* End of statistics **********************

[Frank Mehnert]

Some news: Try to disable the clipboard for that VM (advanced VM settings) and see if the VM still crashes.

[Frank Mehnert]

I think we fixed that problem properly. jwoithe, if you could check if the problem is gone when you disable the clipboard for that VM it would prove my theory.

[Jonathan Woithe]

Sorry for the delay in getting back to your request on the 15th, things have been rather busy.

This morning I tried our 2.0.0 VirtualBox first with no configuration changes, and the VM aborted during startup. This was to confirm that things were still set up correctly. I then changed the clipboard setting from "bidirectional" to "disable" and tried again. The VM started and booted the guest OS. The video performance was atrociously slow, however - much slower than in the past - to the point where you could see the screen redraws happening segment by segment. Later tests (see below) showed that the slow video wasn't due to the clipboard changes, so it must be some unrelated local issue.

Anyway, I then shut the guest OS (win2k) but before the "windows is shutting down" notice appeared the entire guest OS window disappeared from the screen. The lack of the shutdown message might have been due to the slow video performance, however. The main VirtualBox window was totally unresponsive and remained that way for 5 minutes. I then killed it using ctrl-C in the shell which started it. The VM log doesn't note anything out of the ordinary - it finishes with

00:02:40.829 ********************* End of statistics **********************
00:02:41.742 Changing the VM state from 'DESTROYING' to 'TERMINATED'.

I then tried to re-test, since previous experience has shown that even with the clipboard enabled you can sometimes get the VM to start correctly. However, VirtualBox's main window now completely failed to appear at all. Closer inspection showed that VirtualBox hadn't completely shut down:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
jwoithe   1565  0.0  0.0   4432  2036 ?        S    10:38   0:00 /usr/opt/VirtualBox-2.0.0/VBoxXPCOMIPCD
jwoithe   1576  0.0  0.3  38792  7780 ?        Sl   10:38   0:00 /usr/opt/VirtualBox-2.0.0//VBoxSVC --automate

PID 1576 could only be killed with "kill -9", after which I could restart VirtualBox. The status of the VM previous run was then reported as "aborted".

Retrying with the clipboard still disabled behaved similar to the previous run: the VM started, video performance was incredibly slow and after doing a shutdown the status of the VM was reported as "aborted". On this occasion however VirtualBox didn't get hung up and the "saving your settings" message from windows did manage to appear briefly before the guest OS window disappeared.

After changing the clipboard setting back to "bidirectional" I tried the VM again, and this time the VM failed to start - as before the clipboard change. I tried several times to start the VM and after about 6 tries it started. Video performance was still slow, so that seems unrelated to the clipboard changes and is probably due to some separate local issue here. Once the VM started I did a shutdown and it aborted at the end, just like it did with the clipboard changes.

So in summary, from my brief testing it seems that disabling the clipboard improves the ability of Virtualbox to correctly start a VM. However, at least with VirtualBox 2.0.0 there still seems to be an issue during the shutdown of the VM. I notice that 2.0.2 is now out - I will see if I get time to give this a go later today and report any differences.

[Jonathan Woithe]

Although the disabling of the clipboard has improved on the startup issues, one of the higher-level problems described when this ticket was initiated still exists. That is, the VM does not close down cleanly when used via an X11 connection forwarded via SSH. At least it doesn't in 2.0.0. The difficulties with starting the VM under these circumstances appear to be addressed, but after shutting down the VM the VM's status still reverts to "aborted" as described previously (albeit without a segfault, at least in my limited testing so far).

Is it necessary to open a new ticket to get this particular aspect of ticket 2001 addressed? Or is that also going to be fixed in 2.0.4?

As mentioned, in the meantime I'll try 2.0.2 and (when it's out) 2.0.4).