[ SOLVED ] Weird DISPLAY problem with VirtualBox

Please help!

I have a really weird problem with VirtualBox under KDE (freshly compiled from SVN HEAD with mostly standard options). First to make clear - it runs flawlessly under plain Xorg, Gnome2 or Xfce, even when logging in through KDM.

The problem consists solely with KDE:
- when I start VirtualBox from a terminal inside KDE as a normal user I get a segmentation fault
- when I try starting it as root I get:
No protocol specified
Failed to open the X11 display!

I also tried playing with the DISPLAY var. Standard value is :0, setting it to :0.0 or :1.0 didn't help either.

Any clues?

P.S. The value of DISPLAY under Xfce is also :0 - hence no difference to KDE. Maybe KDE uses another var for elaborating and finding screens ... And what could this protocol mean?
 
I didn't know it works in GNOME/Xfce. Probably it crashes in some dbus related code would be my uneducated guess. Can you launch a VM with VBoxSDL or VBoxHeadless in KDE?
 
Hey, thanks a lot for your suggestion. As VBoxManage startvm didn't work, I didn't even try VBoxSDL or VBoxHeadless. But they both work fine!

I forgot to post the complaint of VBoxManage:
Code:
vanessa@inspiron:~ % VBoxManage startvm Windows\ 8.1\ Preview
Type Manifest File: /home/vanessa/.VirtualBox/xpti.dat
nsNativeComponentLoader: autoregistering begins.
nsNativeComponentLoader: autoregistering succeeded
nNCL: registering deferred (0)
Waiting for VM "Windows 8.1 Preview" to power on...

!!Assertion Failed!!
Expression: aI
Location  : /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.18/src/VBox/Main/glue/ErrorInfo.cpp(193) void com::ErrorInfo::init(nsISupports*, const nsID&, bool)
Trace/BPT trap (core dumped)

As for dbus, I don't know what could I have made wrong or different as usual, but I would be very glad about another "uneducated" guess from you :)
 
Thank you for searching for this! No, it makes no difference.
Unfortunately I tried out any tips out there before posting here :(
 
I'm building VirtualBox from ports to see if I also encounter the same problem. And, yes, I do have KDE4 on here.
 
I am having too many troubles with building the port; so, I am asking if someone else is willing to help @vanessa who has the same setup as she does.

Try running a verbose flag and doing null output to a file. Upload this to the FreeBSD emulation mailing list.
 
Last edited by a moderator:
I haven't tryed it yet, but there's a VirtualBox 4.3 port that it's maintainer has asked people to test in the emulation@ mailing list (here).
 
sossego said:
I am having too many troubles with building the port; so, I am asking if someone else is willing to help @vanessa who has the same setup as she does.

Yes, building from ports is tough, I lost a couple of days with it, especially compiling KDE :( Thank you for the good intention :)

I would appreciate a foolproof list of troubleshooting steps as I am running out of ideas.
 
Last edited by a moderator:
xibo said:
I haven't tryed it yet, but there's a VirtualBox 4.3 port that it's maintainer has asked people to test in the emulation@ mailing list (here).

Great, thank you, I'll definitely try it tomorrow! The "stable" version, as the port maintainer refers to the current one, is quite a shaky one ...
 
Here is what I did in the mean time:

  • svn update /usr/src to 11 CURRENT (it was 11 anyway)
  • svn update /usr/ports (also CURRENT)
  • compiled and installed a fresh generic kernel
  • deleted all ports from the system
  • installed only Xorg , KDE4 minimal and VirtualBox

And here are the tests > results:

  1. startx as a regular user > X doesn't find its default xinitrc and closes
  2. added this to the ~/.xinitrc:
    Code:
    twm &
    exec xterm -geometry 80x66+0+0 -name login
    - then startx as a regular user > works
    - VirtualBox in Xterm > works
    - same for VBoxManage and VBoxSDL
    - su to root
    - VirtualBox, VBoxManage and VBoxSDL all open when run as root
  3. added this to the ~/.xinitrc:
    Code:
    exec /usr/local/kde4/bin/startkde
    - startx > KDE Plasma workspace opens
    - VirtualBox in Xterm > Segmentation fault
    - tried in KDE's Terminal as well as with csh, tcsh and bash > same
  4. started KDM as root with service kdm4 onestart
    - logged in as regular user choosing Plasma Workspace > OK
    - trying to start Virtualbox in Xterm > Segmentation fault
    - VBoxManage startvm ... >
    Code:
    Type Manifest File: /home/vanessa/.VirtualBox/xpti.dat
    nsNativeComponentLoader: autoregistering begins.
    nsNativeComponentLoader: autoregistering succeeded
    nNCL: registering deferred (0)
    !!Assertion Failed!!
    Expression: aI
    Location  : /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.18/src/VBox/Main/glue/ErrorInfo.cpp(193) void com::ErrorInfo::init(nsISupports*, const nsID&, bool)
    - su to root
    - VirtualBox >
    Code:
    No protocol specified
    Failed to open the X11 display!
    - VBoxManage startvm ... >
    Code:
    Type Manifest File: /home/vanessa/VirtualBox VMs/xpti.dat
    nsNativeComponentLoader: autoregistering begins.
    *** Registering VirtualBox_Client_Module components (all right -- a generic module!)
    *** Registering VirtualBox_Server_Module components (all right -- a generic module!)
    *** Registering ipcdclient components (all right -- a generic module!)
    nsNativeComponentLoader: autoregistering succeeded
    nNCL: registering deferred (0)
    nsNativeComponentLoader: autoregistering begins.
    nsNativeComponentLoader: autoregistering succeeded
    nNCL: registering deferred (0)
    VBoxManage: error: Failed to create the VirtualBox object!
    VBoxManage: error: Code NS_ERROR_ABORT (0x80004004) - Operation aborted (extended info not available)
    VBoxManage: error: Most likely, the VirtualBox COM server is not running or failed to start.
    ipcDConnectService Stats
     => number of worker threads: 1
    No Persistent Registry Found.
    - VBoxSDL -s ... >
    Code:
    Type Manifest File: /home/vanessa/VirtualBox VMs/xpti.dat
    nsNativeComponentLoader: autoregistering begins.
    nsNativeComponentLoader: autoregistering succeeded
    nNCL: registering deferred (0)
    !!Assertion Failed!!
    Expression: SUCCEEDED (rc)
    Location  : /usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.18/src/VBox/Main/src-client/VirtualBoxClientImpl.cpp(79) nsresult VirtualBoxClient::init()
    COM RC = NS_ERROR_ABORT (0x80004004)
    - VBoxHeadless --startvm ... > same as VBoxSDL
    - logout and log back in as regular user choosing TWM from the KDM drop down > OK
    - VirtualBox in Xterm > WORKS!
    - same for VBoxManage, VBoxSDL and VBoxHeadless - all work


This drives me nuts! It seems that either KDM sets some variables wrong when logging in to Plasma so that a working VirtualBox can't find something it needs or VirtualBox has a bug running under this particular version of KDE.
 
Can you try launching VirtualBox from a x11/konsole instance that runs in XFCE/GNOME/TWM?

EDIT: Is your "KDE from SVN" refering to svn.freebsd.org 's ports repository or to area51?
 
This should help: http://lists.freebsd.org/pipermail/freebsd-emulation/2011-July/008980.html.

Have you tried to disable all possible devices which can disrupt VirtualBox's routine operation? Regarding to VirtualBox 4.3.0 (CFT) status[1], now it's time to warn developers about all the troubles you can find in all phases of post-development. People don't use the mailing lists so much as they should. IMHO this is a big error :\

[1] http://lists.freebsd.org/pipermail/freebsd-emulation/2013-October/010842.html.
 
Well, after reading the mailing list posts it becomes clear that there is no working Virtualbox for FreeBSD 10 or FreeBSD 11. VirtualBox 4.2 works no more (my experience is confirmed by another user in the list) and the posted VirtualBox 4.3 fails to compile :(
 
Re: Weird DISPLAY problem with VirtualBox

Here comes more weird news from KDE and VirtualBox: As I already wrote, running # VirtualBox doesn't work - neither as root, nor as a normal user. But sudo -u vanessa VirtualBox does. Is that not silly?

Does anyone have an idea what's going on here? I can't find another program which behaves like this other than VirtualBox, but again, this happens only under KDE.
 
Re: Weird DISPLAY problem with VirtualBox

When I used it the last time, I had to unset LANG, LC_ALL and remove all files with non-ASCII characters in their name from my home directory. Someone wrote he needs to unset QT_PLUGIN_DIR instead to emulation@ earlier today, which adds to the odds that VirtualBox seems unable to run in a "normal" environment, and it's dedicated environment is probably what sudo provides.

BTW: does it work with sudo on FreeBSD 10?
 
Re: Weird DISPLAY problem with VirtualBox

Yes, it does always work with sudo under 10 and 11 kernels. But how can the environment be different when using sudo?
 
Re: Weird DISPLAY problem with VirtualBox

With the default settings sudo leaves the environment almost completely intact so all enviroment variables that are set for your normal account are in effect for the command run with superuser privileges except those that are related to UID. If I'd have to make a guess this problem probably relates to xauth(1). VirtualBox does not work as the normal user (?) and if you login as root directly the DISPLAY and the required xauth(1) cookie isn't set so the X server refuses the connection. It's a while since I've used X so I don't remember how the xauth(1) stuff should be set up in this case, maybe someone else can help here?
 
Re: Weird DISPLAY problem with VirtualBox

Thank you man! This worked like a charm :) It'd be interesting to know which other variables sudo does NOT keep. But how exactly did you find out that this is because of the QT_PLUGIN_PATH variable?
 
I've removed all my environment variables one by one to see if VirtualBox stops segfaulting and found that QT_PLUGIN_PATH is the one to blame. It will be interesting to update KDE to 4.11.3 to see if the problem persists.
 
Back
Top