Ticket #2001 (closed defect: fixed)

Opened 6 years ago

Last modified 5 years ago

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

Reported by: jwoithe Owned by:
Priority: minor Component: clipboard
Version: VirtualBox 1.6.4 Keywords: segfault ssh tunnel
Cc: Guest type: Windows
Host type: Linux


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[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

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.




VBox.log.bad Download (25.2 KB) - added by rey4 6 years ago.
VBox.log.good Download (25.7 KB) - added by rey4 6 years ago.
VBox.log-bad Download (40.1 KB) - added by jwoithe 6 years ago.
Log generated when the guest OS has been shut down

Change History

comment:1 Changed 6 years ago by frank

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?

comment:2 Changed 6 years ago by frank

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

Changed 6 years ago by rey4

Changed 6 years ago by rey4

comment:3 Changed 6 years ago by rey4

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.

comment:4 Changed 6 years ago by jwoithe

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.

Changed 6 years ago by jwoithe

Log generated when the guest OS has been shut down

comment:5 Changed 6 years ago by jwoithe

Frank: the package I am using is indeed the .run package as you guessed. 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`

comment:6 Changed 6 years ago by jwoithe

Frank: any further news or progress?

comment:7 Changed 6 years ago by frank

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.

comment:8 Changed 6 years ago by jwoithe

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.

comment:9 Changed 6 years ago by frank

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.

comment:10 Changed 6 years ago by jwoithe

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.

comment:11 Changed 6 years ago by Tillmo

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

comment:12 Changed 6 years ago by frank

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

comment:13 Changed 6 years ago by jwoithe

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 **********************

comment:14 Changed 6 years ago by frank

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

comment:15 Changed 6 years ago by frank

  • Component changed from other to clipboard
  • Summary changed from Virtualbox 1.6.4 segfault when displayed via ssh/X11forward to Virtualbox 1.6.4 segfault when displayed via ssh/X11forward => Fixed in 2.0.4

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.

comment:16 Changed 6 years ago by jwoithe

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:

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.

comment:17 Changed 5 years ago by frank

  • Status changed from new to closed
  • Resolution set to fixed

comment:18 Changed 5 years ago by jwoithe

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).

Note: See TracTickets for help on using tickets.
ContactPrivacy policyTerms of Use