VirtualBox

Ticket #7061 (closed defect: fixed)

Opened 4 years ago

Last modified 3 years ago

Segfault in Fedora 13 guest when accessing 3d tools -> fixed as of 24-Nov-2010 for 4.0 and later only

Reported by: noeld Owned by:
Priority: minor Component: 3D support
Version: VirtualBox 3.2.4 Keywords: vboxvideo swrast.c get_window_size
Cc: Guest type: Linux
Host type: Windows

Description

I am running Fedora 13 x86_64 (Goddard), fully patched, under VirtualBox (PUEL edition) 3.2.4. (r62467). The Host OS is win7, 64-bit.

# uname -a
Linux myhost 2.6.33.5-124.fc13.x86_64 #1 SMP Fri Jun 11 09:38:12 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux

Within Fedora running Gnome, when I select System, Preferences, Desktop Effects, the program /usr/bin/desktop-effects crashes with a segmentation fault.

This is the backtrace produced by the crash tool Abrt on Fedora:

[New Thread 2208]
Core was generated by `desktop-effects'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007f47ef671cdb in get_window_size (ctx=0x13f7490, 
    fb=<value optimized out>) at swrast.c:441
441	swrast.c: No such file or directory.
	in swrast.c

Thread 1 (Thread 2208):
#0  0x00007f47ef671cdb in get_window_size (ctx=0x13f7490, 
    fb=<value optimized out>) at swrast.c:441
        buf = 0x1728ef0
        screen = 0x12ac350
        x = 0
        y = 19647264
#1  swrast_check_and_update_window_size (ctx=0x13f7490, 
    fb=<value optimized out>) at swrast.c:451
        width = 54
        height = -2145113757
#2  0x00007f47ef671d5d in driBindContext (ctx=0x13f7490, draw=0x1728ef0, 
    read=0x1728ef0) at swrast.c:616
        mesaCtx = 0x13f7490
        mesaDraw = 0x1728ef0
        mesaRead = 0x1728ef0
#3  0x0000003680224d69 in MakeContextCurrent (dpy=0x124f200, draw=69206022, 
    read=69206022, gc=0x12bcb20) at glxcurrent.c:402
        pdraw = 0x7fff3ff9398c
        pread = <value optimized out>
        oldGC = 0x3680468580
        reply = {type = 6 '\006', unused = 0 '\000', sequenceNumber = 1056, 
          length = 0, contextTag = 1810119199, pad2 = 54, pad3 = 19242488, 
          pad4 = 0, pad5 = 1809976991, pad6 = 54}
        opcode = 153 '\231'
        oldOpcode = 153 '\231'
        bindReturnValue = <value optimized out>
        state = <value optimized out>
#4  0x0000000000403126 in has_hardware_gl (argc=1, argv=0x7fff3ff93c78)
    at desktop-effects.c:1005
        xdisplay = 0x124f200
        renderer = <value optimized out>
        window = 69206022
        attrlist = {4, 8, 1, 9, 1, 10, 1, 5, 0}
        screen = <value optimized out>
        cwa = {background_pixmap = 0, background_pixel = 0, 
          border_pixmap = 0, border_pixel = 0, bit_gravity = 0, 
          win_gravity = 0, backing_store = 0, backing_planes = 0, 
          backing_pixel = 0, save_under = 0, event_mask = 0, 
          do_not_propagate_mask = 0, override_redirect = 0, 
          colormap = 69206021, cursor = 0}
        xscreen = <value optimized out>
        context = 0x12bcb20
        visual = <value optimized out>
        success = 0
#5  main (argc=1, argv=0x7fff3ff93c78) at desktop-effects.c:1064
        app = <value optimized out>
        err = 0x0
From                To                  Syms Read   Shared Object Library
0x0000003673211b30  0x000000367322da28  Yes         /usr/lib64/libgconf-2.so.4
0x0000003680220680  0x000000368024c568  Yes         /usr/lib64/libGL.so.1
0x0000003682a09390  0x0000003682a140e8  Yes         /usr/lib64/libglade-2.0.so.0
0x0000003671a681c0  0x0000003671d0d268  Yes         /usr/lib64/libgtk-x11-2.0.so.0
0x000000367262c950  0x0000003672709048  Yes         /usr/lib64/libxml2.so.2
0x000000366f21d260  0x000000366f27f2a8  Yes         /usr/lib64/libgdk-x11-2.0.so.0
0x00000036712096b0  0x00000036712150f8  Yes         /usr/lib64/libatk-1.0.so.0
0x000000366b619b60  0x000000366b6812c8  Yes         /lib64/libgio-2.0.so.0
0x000000366fe07650  0x000000366fe21348  Yes         /usr/lib64/libpangoft2-1.0.so.0
0x000000366ee05940  0x000000366ee17ba8  Yes         /usr/lib64/libgdk_pixbuf-2.0.so.0
0x000000366e604630  0x000000366e608eb8  Yes         /usr/lib64/libpangocairo-1.0.so.0
0x000000366fa09c50  0x000000366fa5b058  Yes         /usr/lib64/libcairo.so.2
0x000000367020ede0  0x000000367022d768  Yes         /usr/lib64/libpango-1.0.so.0
0x000000366d20c850  0x000000366d2745a8  Yes         /usr/lib64/libfreetype.so.6
0x000000366d605c80  0x000000366d61ff28  Yes         /usr/lib64/libfontconfig.so.1
0x000000366a608d20  0x000000366a632a78  Yes         /lib64/libgobject-2.0.so.0
0x000000366b201080  0x000000366b201fc8  Yes         /lib64/libgmodule-2.0.so.0
0x000000366aa01590  0x000000366aa029f8  Yes         /lib64/libgthread-2.0.so.0
0x0000003668e02140  0x0000003668e055a8  Yes         /lib64/librt.so.1
0x0000003669a155c0  0x0000003669a99d58  Yes         /lib64/libglib-2.0.so.0
0x000000366f600b40  0x000000366f601908  Yes         /usr/lib64/libXcomposite.so.1
0x0000003671601370  0x0000003671604178  Yes         /usr/lib64/libXfixes.so.3
0x000000366be1dd80  0x000000366beab938  Yes         /usr/lib64/libX11.so.6
0x0000003668605640  0x0000003668610e48  Yes         /lib64/libpthread.so.0
0x000000366821e9a0  0x000000366832b9e0  Yes         /lib64/libc.so.6
0x0000003672a27990  0x0000003672a4b6a8  Yes         /usr/lib64/libORBit-2.so.0
0x000000366ae07090  0x000000366ae2e4c8  Yes         /lib64/libdbus-1.so.3
0x000000366ce03580  0x000000366ce0e768  Yes         /usr/lib64/libXext.so.6
0x000000367de00e30  0x000000367de03d08  Yes         /usr/lib64/libXxf86vm.so.1
0x0000003670e00a90  0x0000003670e01638  Yes         /usr/lib64/libXdamage.so.1
0x0000003680a02f90  0x0000003680a07858  Yes         /usr/lib64/libdrm.so.2
0x0000003669203ea0  0x0000003669243fa8  Yes         /lib64/libm.so.6
0x0000003668a00de0  0x0000003668a01998  Yes         /lib64/libdl.so.2
0x0000003669601ef0  0x000000366960d228  Yes         /lib64/libz.so.1
0x0000003670a018c0  0x0000003670a07f58  Yes         /usr/lib64/libXrender.so.1
0x0000003672200a20  0x0000003672201508  Yes         /usr/lib64/libXinerama.so.1
0x000000366de01eb0  0x000000366de0c608  Yes         /usr/lib64/libXi.so.6
0x000000366ea01720  0x000000366ea06828  Yes         /usr/lib64/libXrandr.so.2
0x0000003670602880  0x0000003670607678  Yes         /usr/lib64/libXcursor.so.1
0x000000366a2038c0  0x000000366a212528  Yes         /lib64/libresolv.so.2
0x0000003669e05550  0x0000003669e15038  Yes         /lib64/libselinux.so.1
0x000000366da04830  0x000000366da1e7a8  Yes         /usr/lib64/libpng12.so.0
0x000000366e207230  0x000000366e251e78  Yes         /usr/lib64/libpixman-1.so.0
0x000000366c603b70  0x000000366c61ca08  Yes         /lib64/libexpat.so.1
0x0000003667e00af0  0x0000003667e18934  Yes         /lib64/ld-linux-x86-64.so.2
0x000000366c208650  0x000000366c213898  Yes         /usr/lib64/libxcb.so.1
0x000000366ba00dd0  0x000000366ba01b68  Yes         /usr/lib64/libXau.so.6
0x00007f47f1080110  0x00007f47f1088278  Yes         /lib64/libnss_files.so.2
0x00007f47f0e6d910  0x00007f47f0e7b0d8  Yes         /usr/lib64/gtk-2.0/2.10.0/engines/libglide.so
0x00007f47f0c69620  0x00007f47f0c69e08  Yes         /usr/lib64/gtk-2.0/modules/libpk-gtk-module.so
0x000000366ca08f70  0x000000366ca194a8  Yes         /usr/lib64/libdbus-glib-1.so.2
0x00007f47f0a63fb0  0x00007f47f0a661e8  Yes         /usr/lib64/gtk-2.0/modules/libcanberra-gtk-module.so
0x0000003681201c60  0x00000036812030a8  Yes         /usr/lib64/libcanberra-gtk.so.0
0x0000003680603280  0x000000368060c318  Yes         /usr/lib64/libcanberra.so.0
0x000000367e601fa0  0x000000367e605fd8  Yes         /usr/lib64/libvorbisfile.so.3
0x000000367ca03700  0x000000367ca1a718  Yes         /usr/lib64/libvorbis.so.0
0x000000367be018a0  0x000000367be03bb8  Yes         /usr/lib64/libogg.so.0
0x000000367c601e30  0x000000367c609ca8  Yes         /usr/lib64/libtdb.so.1
0x000000367a202370  0x000000367a206758  Yes         /usr/lib64/libltdl.so.7
0x00007f47f08f9e30  0x00007f47f0928958  Yes (*)     /usr/lib64/dri/vboxvideo_dri.so
0x00007f47f07a60d0  0x00007f47f07b8388  Yes (*)     /usr/lib64/VBoxOGLcrutil.so
0x00007f47f0532d90  0x00007f47f0635298  Yes (*)     /usr/lib64/VBoxOGLpackspu.so
0x00007f47f04056e0  0x00007f47f040ae18  Yes (*)     /usr/lib64/VBoxOGLerrorspu.so
0x00007f47efcba920  0x00007f47efd2b838  Yes (*)     /usr/lib64/VBoxOGLfeedbackspu.so
0x00007f47efba2660  0x00007f47efba68a8  Yes (*)     /usr/lib64/VBoxOGLpassthroughspu.so
0x00007f47ef670540  0x00007f47ef7b86d8  Yes         /usr/lib64/dri/swrast_dri.so
(*): Shared library is missing debugging information.
$1 = 0x0
$2 = 0x0
rax            0x0	0
rbx            0x1728ef0	24284912
rcx            0x7fff3ff9398c	140734266685836
rdx            0x7fff3ff93980	140734266685824
rsi            0x7fff3ff93984	140734266685828
rdi            0x1728ef0	24284912
rbp            0x13f7490	0x13f7490
rsp            0x7fff3ff93980	0x7fff3ff93980
r8             0x7fff3ff93988	140734266685832
r9             0x1728eb0	24284848
r10            0x18	24
r11            0x7f47ef671d0c	139946935917836
r12            0x1728ef0	24284912
r13            0x4200006	69206022
r14            0x4200006	69206022
r15            0x99	153
rip            0x7f47ef671cdb	0x7f47ef671cdb <swrast_check_and_update_window_size+51>
eflags         0x10202	[ IF RF ]
cs             0x33	51
ss             0x2b	43
ds             0x0	0
es             0x0	0
fs             0x0	0
gs             0x0	0
Dump of assembler code for function swrast_check_and_update_window_size:
   0x00007f47ef671ca8 <+0>:	push   %rbp
   0x00007f47ef671ca9 <+1>:	mov    %rdi,%rbp
   0x00007f47ef671cac <+4>:	push   %rbx
   0x00007f47ef671cad <+5>:	mov    %rsi,%rbx
   0x00007f47ef671cb0 <+8>:	mov    %rbx,%rdi
   0x00007f47ef671cb3 <+11>:	sub    $0x18,%rsp
   0x00007f47ef671cb7 <+15>:	mov    0x438(%rsi),%rax
   0x00007f47ef671cbe <+22>:	mov    0x430(%rbx),%r9
   0x00007f47ef671cc5 <+29>:	mov    %rsp,%rdx
   0x00007f47ef671cc8 <+32>:	lea    0xc(%rsp),%rcx
   0x00007f47ef671ccd <+37>:	lea    0x4(%rsp),%rsi
   0x00007f47ef671cd2 <+42>:	lea    0x8(%rsp),%r8
   0x00007f47ef671cd7 <+47>:	mov    0x10(%rax),%rax
=> 0x00007f47ef671cdb <+51>:	callq  *0x10(%rax)
   0x00007f47ef671cde <+54>:	mov    0xc(%rsp),%edx
   0x00007f47ef671ce2 <+58>:	cmp    %edx,0x114(%rbx)
   0x00007f47ef671ce8 <+64>:	jne    0x7f47ef671cf6 <swrast_check_and_update_window_size+78>
   0x00007f47ef671cea <+66>:	mov    0x118(%rbx),%eax
   0x00007f47ef671cf0 <+72>:	cmp    0x8(%rsp),%eax
   0x00007f47ef671cf4 <+76>:	je     0x7f47ef671d05 <swrast_check_and_update_window_size+93>
   0x00007f47ef671cf6 <+78>:	mov    0x8(%rsp),%ecx
   0x00007f47ef671cfa <+82>:	mov    %rbx,%rsi
   0x00007f47ef671cfd <+85>:	mov    %rbp,%rdi
   0x00007f47ef671d00 <+88>:	callq  0x7f47ef695dda <_mesa_resize_framebuffer>
   0x00007f47ef671d05 <+93>:	add    $0x18,%rsp
   0x00007f47ef671d09 <+97>:	pop    %rbx
   0x00007f47ef671d0a <+98>:	pop    %rbp
   0x00007f47ef671d0b <+99>:	retq   
End of assembler dump.

I initially reported the issue to Fedora but their developers say that the problem lies within the display drivers used by VirtualBox. The Bugzilla ticket is here:  https://bugzilla.redhat.com/show_bug.cgi?id=603569

After I installed Fedora 13 I patched it, then mounted the Guest Additions DVD and ran VBoxLinuxAdditions-amd64.run. It completed successfully.

# ./VBoxLinuxAdditions-amd64.run 
Verifying archive integrity... All good.
Uncompressing VirtualBox 3.2.4 Guest Additions for Linux........
VirtualBox Guest Additions installer
Removing installed version 3.2.4 of VirtualBox Guest Additions...
Building the VirtualBox Guest Additions kernel modules
Building the main Guest Additions module                   [  OK  ]
Building the shared folder support module                  [  OK  ]
Building the OpenGL support module                         [  OK  ]
Doing non-kernel setup of the Guest Additions              [  OK  ]
You should restart your guest to make sure the new modules are actually used

Installing the Window System drivers
Installing X.Org Server 1.8 modules                        [  OK  ]
Setting up the Window System to use the Guest Additions    [  OK  ]
The following X.Org/XFree86 configuration files were originally generated by
the VirtualBox Guest Additions and were not modified:

  /etc/X11/xorg.conf

You may need to restart the hal service and the Window System (or just restart
the guest system) to enable the Guest Additions.

Installing graphics libraries and desktop services componen[  OK  ]

I can also causes a segmentation fault by running opengl tools like glxinfo and glxgears.

The VM is allocated 128MB of RAM for video memory and 3d acceleration is enabled.

# glxinfo
name of display: :0.0
Segmentation fault (core dumped)

# gdb /usr/bin/glxinfo core.5998 
GNU gdb (GDB) Fedora (7.1-26.fc13)
Copyright (C) 2010 Free Software Foundation, Inc.
[...]

Core was generated by `glxinfo'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007f69a57adcdb in get_window_size (ctx=0x1033770, fb=<value optimized out>)
    at swrast.c:441
441	    screen->swrast_loader->getDrawableInfo(buf,

(gdb) bt
#0  0x00007f69a57adcdb in get_window_size (ctx=0x1033770, fb=<value optimized out>)
    at swrast.c:441
#1  swrast_check_and_update_window_size (ctx=0x1033770, fb=<value optimized out>) at swrast.c:451
#2  0x00007f69a57add5d in driBindContext (ctx=0x1033770, draw=0x13651b0, read=0x13651b0)
    at swrast.c:616
#3  0x0000003680224d69 in MakeContextCurrent (dpy=0xedb010, draw=88080388, read=88080388, 
    gc=0xef8200) at glxcurrent.c:402
#4  0x0000000000401ae9 in print_screen_info (dpy=0xedb010, scrnum=0, allowDirect=1, 
    limits=0 '\000') at glxinfo.c:482
#5  0x0000000000402943 in main (argc=1, argv=0x7fff7065fe28) at glxinfo.c:1181

I cannot think of anything else to add. I will be happy to provide more information but please bear in mind that my timezone is NZST, GMT+12.

Attachments

Redhat64-2010-06-25-14-45-38.log Download (60.6 KB) - added by noeld 4 years ago.
Virtualbox Log file
VBox.log Download (55.4 KB) - added by gblues 3 years ago.
Virtualbox log from crash using 3.2.11 addons
hoeferbe_CentOS5_host_log_of_Fedora14_guest_VBox.log Download (45.5 KB) - added by hoeferbe 3 years ago.
The VBox.log file for my Fedora14 guest off my host CentOS5 machine.
hoeferbe_Fedora14_guest_glxinfo_with_debug.txt Download (20.3 KB) - added by hoeferbe 3 years ago.
Running glxinfo on my Fedora14 guest with debug turned on.
hoeferbe_Fedora14_guest_Xorg.0.log Download (20.6 KB) - added by hoeferbe 3 years ago.
Xorg.0.log file from my Fedora 14 guest.

Change History

Changed 4 years ago by noeld

Virtualbox Log file

comment:1 Changed 4 years ago by backvan

Add

I'm having the same issue with Desktop Effects crashing my host. Host is iMac 27" Intel i7 (Snow Leopard 10.6.3) and guest is Fedora13 (2.6.33.5-124.fc13.i686). VBox is 4.2.6. Guest additions seems to be installed properly. I'm getting up to 2560x1440 display size but have reduced it down to 1600x900. Shared Folders works great. Host crashes no matter the screen resolution. But there is a twist. On the same host and VBox, three flavors of Ubuntu 10.04 work perfectly with Desktop Effects. Also a miniMac with Leopard and same VBox and same Fedora13 work perfectly. The iMac has a ATI Radeon HD 4850 Graphics Chip. It's not clear to me exactly where the problem really is. Maybe there is still a problem with the Guest Additions install even though NO errors were apparent. All my Guest Hosts are 32 bit versions.

If you need more info, logs, etc, please ask.

Thanks

backvan

comment:2 Changed 4 years ago by chuckh1958

Same issue here. I am using gnome but not desktop effects. X server crashes with segmentation fault whenever it tries to start. This is only in virtualbox and started with the latest update of xorg-server.

comment:3 in reply to: ↑ description Changed 4 years ago by hoeferbe

Same issue here. I have an x86_64 CentOS 5 machine running VirtualBox 3.2.6. (Was 3.16.) The machine has an ATI Radeon HD 2600XT and I use the proprietary drivers. Glxgears works fine on it (the host).

I have Fedora 12 (x86_64) installed as a VirturalBox guest. The VirtualBox guest additions installed successfully. Yet, when I execute glxgears in the Fedora 12 guest, it crashes. The backtrace shows that it, too, has a problem with swrast.c's get_window_size. I submitted a bug to Red Hat in late April 2010, but no action has been taken on it:

 https://bugzilla.redhat.com/show_bug.cgi?id=585605

My Windows XP guest has no problems with 3D acceleration.

comment:4 follow-up: ↓ 5 Changed 4 years ago by galalleni

Same issue here. It appears that the system is using Mesa's libGL (which is v7.8) instead of the libGL Vbox uses (v7.2) - that's why this error is occurring.

comment:5 in reply to: ↑ 4 Changed 4 years ago by hoeferbe

Replying to galalleni:

===

Same issue here. It appears that the system is using Mesa's libGL (which is v7.8) instead of the libGL Vbox uses (v7.2) - that's why this error is occurring.

===

So does this mean that nobody with Fedora 12 or 13 can get 3D acceleration working?

My Fedora 12 guest is using mesa-libGL-7.7-4.fc12. Ubuntu 10.04 uses  mesa-libGL 7.7.1. Yet I've seen posts from those users with working 3D acceleration. Why is that?

Thank you for explaining this issue and for any recommendations on how to work around it.

comment:6 Changed 4 years ago by galalleni

I just ran glxinfo in gdb and found that the screen->swrast_loader in get_window_size is a null pointer - meaning __DRIswrastLoaderExtension is not initialized in the default private __DRIscreen when it should be. I'm really a novice when it comes to DRI/GLX/Mesa, but I do know that dereferencing null pointers is a bad idea. grep'ing the Vbox source I can't find any file that defines swrast_loader - so I'm figuring it's new to mesa and thus not in Vbox.

Versions of Mesa greater than 7.2 (such as 7.7.4) might play nicely because they use the same struct's and are setup similarly, and are backwards compatible. However, mesa 7.8 might have changed something (like the swrast_loader) which has broken compatibility.

What could fix this is using an old libGL.so that doesn't have the swrast_loader, something that would behave nicely with vbox. I am by no means an expert - but I do know other drivers replace libGL.so with a custom version to get the driver to play nicely with the system (e.g. the nvidia driver). In my Fedora 13 install, libGL.so is the one from Mesa 7.8.1, not one provided by any vbox package - and I'm noticing things don't work right, even for simple GLX applications - telling me libGL.so is not playing nicely with the vbox driver.

Again - I'm not an expert, but that's how the problem looks to me.

comment:7 Changed 4 years ago by Technologov

I have a similar issue in Fedora12 x64 -- Bug #7531

-Technologov

comment:8 follow-up: ↓ 9 Changed 4 years ago by axdp944

I've documented a potential workaround for this problem in the vb forums here:

 http://forums.virtualbox.org/viewtopic.php?f=6&t=32321&p=157027#p157027

In Fedora 13, downgrading mesa-libGL, mesa-libGLU and mesa-dri-drivers from v7.8 to the v7.5 used in Fedora 11 seems to be a good temporary workaround until this bug is resolved.

comment:9 in reply to: ↑ 8 Changed 3 years ago by hoeferbe

Update: I've upgraded to VirtualBox-3.2-3.2.10_66523_rhel5-1.x86_64 on the host and updates the Fedora 12's Guest Additions. Still no go.

Replying to axdp944:
===

I've documented a potential workaround for this problem in the vb forums here:

 http://forums.virtualbox.org/viewtopic.php?f=6&t=32321&p=157027#p157027

===

Thanks! I also read your 2010-10-10 comment about it crashing again after a few days.

I went ahead and tried your work around, anyway, and it didn't work even a little bit. I removed these packages from my Fedora 12 guest:

glx-utils-7.7-4.fc12.x86_64
mesa-dri-drivers-7.7-4.fc12.x86_64
mesa-libGL-7.7-4.fc12.x86_64
mesa-libGLU-7.7-4.fc12.x86_64

downloaded and installed these packages from a Fedora 11 repository:

glx-utils-7.5-0.14.fc11.x86_64
mesa-dri-drivers-7.5-0.14.fc11.x86_64
mesa-libGL-7.5-0.14.fc11.x86_64
mesa-libGLU-7.5-0.14.fc11.x86_64

and then rebooted. Glxinfo still dumps core. I ran "strace glxinfo" and nothing stood out to me except several attempts to open files that did not exist:

/lib64/tls/x86_64/VBoxOGLcrutil.so
/lib64/tls/VBoxOGLcrutil.so
/lib64/x86_64/VBoxOGLcrutil.so
/lib64/VBoxOGLcrutil.so
/usr/lib64/tls/x86_64/VBoxOGLcrutil.so
/usr/lib64/tls/VBoxOGLcrutil.so
/usr/lib64/x86_64/VBoxOGLcrutil.so

Seeing how those are all the same file, I'm guessing glxinfo just looks for that library in several standard places until it finds it. So, the "No such file or directory" errors in the strace are no big deal.

comment:10 in reply to: ↑ description Changed 3 years ago by gblues

I am having the same problem with Fedora 14 x86_64 guest and VirtualBox 3.2.10 on Windows 7 Pro host.

comment:11 follow-up: ↓ 12 Changed 3 years ago by michael

Those experiencing this can test out this Additions build from the stable tree (disclaimer here):

 http://www.virtualbox.org/download/testcase/VBoxGuestAdditions-r68088.iso

comment:12 in reply to: ↑ 11 ; follow-up: ↓ 13 Changed 3 years ago by hoeferbe

Replying to michael:

===

Those experiencing this can test out this Additions build from the stable tree

===

Thanks, Michael! I tested your r68088 of the Guest Additions on my x86_64 Fedora 12 guest and it worked!

I've only tried glxinfo & glxgears. I get about 1,055 frames per second (FPS) from my guest's glxgears. That is about 1/8 what I get on the host. I don't know if that large of a decrease in performance is normal or not, but thought I'd mention it just in case it was not.

I'm just happy that this now appears to be working. Are there any particular tests you want me to run my machine through? Thanks again!

comment:13 in reply to: ↑ 12 ; follow-up: ↓ 22 Changed 3 years ago by michael

Replying to hoeferbe:

[...] Are there any particular tests you want me to run my machine through?

The best test would be to keep on using those Additions for your day-to-day work with the virtual machine. Apart from that fix they match exactly what the Additions would look like if we did a minor release today, and if we do a minor release in the near future I will prepare a matching "fixed" Additions build if anything non-trivial has changed since now. I am reasonably sure that the fix solves the problem it was intended to, but we would like a bit of testing to be sure that no other 3D-related regressions occur (I don't think they will, but the fix was sufficiently tricky that it is hard to say for sure).

comment:14 Changed 3 years ago by gblues

I have two systems I'm running VirtualBox on. I haven't tested the desktop yet.

The good news is, glxinfo doesn't dump core anymore. The bad news is that now VirtualBox itself crashes completely.

Host OS & VER: Windows 7 Home Ultimate Host GPU: Mobile Intel 4 series CPU: Core 2 Duo (no VT-X support) Guest OS: Fedora 14 32-bit

comment:15 follow-up: ↓ 16 Changed 3 years ago by gblues

I've just tested it with my desktop. It doesn't crash, but it's not 100% either.

Host OS & VER: Windows 7 Pro Host CPU: AMD Phenom II X4 940 (3.0Ghz) Host GPU: NVidia GeForce 8600 GTS Guest OS & VER: Fedora 14 64-bit

+ glxinfo and compiz launch without crashing! + desktop effects seem to work smoothly.

  • Window dressing (title bar, close/minimize/maximize buttons) disappears in Seamless Mode. The missing dressing reappears if I exit seamless mode.

comment:16 in reply to: ↑ 15 ; follow-up: ↓ 17 Changed 3 years ago by hoeferbe

Replying to gblues:
===

I've just tested it with my desktop. It doesn't crash, but it's not 100% either.

Host OS & VER: Windows 7 Pro
Host CPU: AMD Phenom II X4 940 (3.0Ghz)
Host GPU: NVidia GeForce 8600 GTS
Guest OS & VER: Fedora 14 64-bit

===

After seeing your comments, I quickly installed a Fedora 14 x86_64 guest, taking all the defaults. (For my CentOS5 host system's details, please see my comment above.) Mine didn't crash, but it performed significantly worse than my Fedora 12 x86_64 guest.

Just to recap: running glxgears on my host results in an average of ~8,480 FPS. With the r68088 Guest Additions, I'm able to get 1,055 FPS in my Fedora 12 guest. My test on my Fedora 14 guest resulted in a very disappointing ~200 FPS.

I re-sized my two Fedora guests to be windows on my host and ran glxgears in each at the same time:

CentOS5 host dropped to ~6,640 FPS. (21.7% decrease)
Fedora 12 guest dropped to ~830 FPS. (21.3% decrease)
Fedora 14 guest dropped to ~39 FPS. (80.5% decrease)[[BR]]

comment:17 in reply to: ↑ 16 ; follow-up: ↓ 19 Changed 3 years ago by leonid

Just to recap: running glxgears on my host results in an average of ~8,480 FPS. With the r68088 Guest Additions, I'm able to get 1,055 FPS in my Fedora 12 guest. My test on my Fedora 14 guest resulted in a very disappointing ~200 FPS.

I re-sized my two Fedora guests to be windows on my host and ran glxgears in each at the same time:

CentOS5 host dropped to ~6,640 FPS. (21.7% decrease)
Fedora 12 guest dropped to ~830 FPS. (21.3% decrease)
Fedora 14 guest dropped to ~39 FPS. (80.5% decrease)[[BR]]

First, using glxgears to measure 3d performance ain't the best idea because it's very "simple" in terms of 3d scene composition, and as all other cases with high fps count (>1k) it shifts bottleneck from actual 3d processing to various other sync issues.

Second, 39fps in glxgears means that 99% you don't have 3d acceleration enabled/working. It's most likely Mesa's software rendering, so please try running glxinfo and check it.

Changed 3 years ago by gblues

Virtualbox log from crash using 3.2.11 addons

comment:18 Changed 3 years ago by gblues

I've attached the log from where VirtualBox crashes when attempting to use 3d. When I attach a debugger to the crash, I get this oh-so-useful message:

Unhandled exception at 0x056eee1f in VirtualBox.exe: 0xC0000005: Access violation writing location 0x00000000000001b8.

comment:19 in reply to: ↑ 17 Changed 3 years ago by hoeferbe

Replying to leonid:
===

First, using glxgears to measure 3d performance ain't the best idea

===

Thanks for informing me of that. Other than plain-jane use of 3D for games, I'm a newbie in this realm. So what way should I compare the performance of one machine's 3D acceleration to another. Most of the lines outputted from glxinfo mean nothing to me.

===

Second, 39fps in glxgears means that 99% you don't have 3d
acceleration enabled/working. It's most likely Mesa's software
rendering, so please try running glxinfo and check it.

===

You're right:

# glxinfo | grep -i vendor
server glx vendor string: SGI
client glx vendor string: Mesa Project and SGI
OpenGL vendor string: Mesa Project

That is strange that the Fedora 14 guest is not using the 3D acceleration. The only errors or warnings I see from Xorg are:

(EE) [drm] drmOpen failed.
(EE) VBoxVideo(0): DRIScreenInit failed, disabling DRI.

which I assume to be similiar to what I see in my (working) Fedora 12 guest:

(EE) AIGLX error: vboxvideo does not export required DRI extension
(EE) AIGLX: reverting to software rendering

As far as I can tell, the Fedora 14 guest is using the VirtualBox driver from the Guest Additions:

(II) Loading /usr/lib64/xorg/modules/drivers/vboxvideo_drv.so
(II) VBoxVideo: guest driver for VirtualBox: vbox
(II) VBoxVideo(0): VirtualBox guest additions video driver version 3.2.11

comment:20 follow-up: ↓ 24 Changed 3 years ago by leonid

gblues: Could you try updating your host drivers? According to Intel's site  http://downloadcenter.intel.com/SearchResult.aspx?lang=eng&ProductFamily=Graphics&ProductLine=Laptop+graphics+controllers&ProductProduct=Mobile+Intel%c2%ae+4+Series+Express+Chipset+Family the drivers you use (8.15.10.1883) are quite old and there're recent 8.15.10.2226.

hoeferbe: Please check if you have 3d acceleration enabled for your fedora vm. If it is, attach a host log and result of running CR_DEBUG=1 LIBGL_DEBUG=verbose glxinfo from the guest.

(EE) [drm] drmOpen failed.
(EE) VBoxVideo(0): DRIScreenInit failed, disabling DRI.

That's quite strange, and opengl acceleration wouldn't work as long as this message is in the log. If previous logs wouldn't show smething meaningfull attaching full var/Xorg.0.log might be a good idea too.

comment:21 Changed 3 years ago by gblues

Thank you for the link to the generic Intel drivers. My OEM (Toshiba) hasn't released a matching update, and the Intel driver isn't certified for my particular laptop (both the Intel installer and the Windows Driver Update failed to automatically install it). Since Windows has the driver rollback feature, I took a chance and forced it to install the Intel driver via the "Have Disk" method and the driver installed successfully. So if there's anyone else with a Satellite A505-S6960, the generic drivers work!

With the generic Intel driver installed, VirtualBox no longer crashes when accessing 3d functions, and I can now use compiz similar to my desktop (the hardware performance differences between the Intel GMA and nVidia 8600 GTS notwithstanding). I experience the missing window dressing in Seamless Mode with compiz enabled on both my laptop and desktop systems, pointing to a VB issue rather than a driver issue.

comment:22 in reply to: ↑ 13 Changed 3 years ago by gblues

Replying to michael:

Replying to hoeferbe:

[...] Are there any particular tests you want me to run my machine through?

The best test would be to keep on using those Additions for your day-to-day work with the virtual machine. Apart from that fix they match exactly what the Additions would look like if we did a minor release today, and if we do a minor release in the near future I will prepare a matching "fixed" Additions build if anything non-trivial has changed since now. I am reasonably sure that the fix solves the problem it was intended to, but we would like a bit of testing to be sure that no other 3D-related regressions occur (I don't think they will, but the fix was sufficiently tricky that it is hard to say for sure).

Apparently your fix was not included in the 3.2.12 release because the problem has returned. Can you provide an updated fix for 3.2.12 guest additions? Thanks!

comment:23 Changed 3 years ago by michael

I refreshed the link above. There were no relevant changes between that image and the Additions included in 3.2.12. However we don't plan to include this in released versions of 3.2 as it is too big a change for an existing stable branch.

comment:24 in reply to: ↑ 20 Changed 3 years ago by hoeferbe

Replying to leonid:
===

hoeferbe:
Please check if you have 3d acceleration enabled for your fedora vm.

===

I do. In the VirtualBox guest list window, clicking on my Fedora 14 guest shows "3d Acceleration" "Enabled" in the right window pane. (And I've also confirmed that my guest's $HOME/.VirtualBox/Machines/F14/F14.xml has:

accelerated3D="true"

in it.)

===

If it is, attach a host log and result of running CR_DEBUG=1 LIBGL_DEBUG=verbose glxinfo from the guest.

===

Please find hoeferbe_Fedora14_guest_glxinfo_with_debug.txt and hoeferbe_CentOS5_host_log_of_Fedora14_guest_VBox.log attached to this ticket.

===

{{{
(EE) [drm] drmOpen failed.
(EE) VBoxVideo(0): DRIScreenInit failed, disabling DRI.
}}}
That's quite strange, and opengl acceleration wouldn't work as long as this message is in the log. If previous logs wouldn't show smething meaningfull attaching full var/Xorg.0.log might be a good idea too.

===

Yes, it has become obvious to me that my Fedora 14 guest does not think it has 3D acceleration. I have attached hoeferbe_Fedora14_guest_Xorg.0.log. I see a "[drm] failed to load kernel module "vboxvideo"" error in it.

Changed 3 years ago by hoeferbe

The VBox.log file for my Fedora14 guest off my host CentOS5 machine.

Changed 3 years ago by hoeferbe

Running glxinfo on my Fedora14 guest with debug turned on.

Changed 3 years ago by hoeferbe

Xorg.0.log file from my Fedora 14 guest.

comment:25 Changed 3 years ago by michael

  • Status changed from new to closed
  • Resolution set to fixed
  • Summary changed from Segfault in swrast.c:get_window_size() (vboxvideo) in Fedora 13 when accessing 3d tools to Segfault in Fedora 13 guest when accessing 3d tools -> fixed as of 24-Nov-2010 for 4.0 and later only

I will close this as the main issue under discussion was fixed. If the problem with vboxvideo not loading in the F14 guest is still relevant you could open a new ticket for that (or better, find an existing one if possible).

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use