Opened 15 years ago
Closed 14 years ago
#7061 closed defect (fixed)
Segfault in Fedora 13 guest when accessing 3d tools -> fixed as of 24-Nov-2010 for 4.0 and later only
Reported by: | Noel | Owned by: | |
---|---|---|---|
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 (5)
Change History (30)
by , 15 years ago
Attachment: | Redhat64-2010-06-25-14-45-38.log added |
---|
comment:1 by , 15 years ago
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 by , 15 years ago
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 by , 15 years ago
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.
follow-up: 5 comment:4 by , 14 years ago
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 by , 14 years ago
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 by , 14 years ago
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.
follow-up: 9 comment:8 by , 14 years ago
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 by , 14 years ago
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 by , 14 years ago
I am having the same problem with Fedora 14 x86_64 guest and VirtualBox 3.2.10 on Windows 7 Pro host.
follow-up: 12 comment:11 by , 14 years ago
Those experiencing this can test out this Additions build from the stable tree (disclaimer here):
http://www.virtualbox.org/download/testcase/VBoxGuestAdditions-r68088.iso
follow-up: 13 comment:12 by , 14 years ago
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!
follow-up: 22 comment:13 by , 14 years ago
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 by , 14 years ago
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
follow-up: 16 comment:15 by , 14 years ago
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.
follow-up: 17 comment:16 by , 14 years ago
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]]
follow-up: 19 comment:17 by , 14 years ago
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.
comment:18 by , 14 years ago
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 by , 14 years ago
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
follow-up: 24 comment:20 by , 14 years ago
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 by , 14 years ago
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 by , 14 years ago
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 by , 14 years ago
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 by , 14 years ago
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.
by , 14 years ago
Attachment: | hoeferbe_CentOS5_host_log_of_Fedora14_guest_VBox.log added |
---|
The VBox.log file for my Fedora14 guest off my host CentOS5 machine.
by , 14 years ago
Attachment: | hoeferbe_Fedora14_guest_glxinfo_with_debug.txt added |
---|
Running glxinfo on my Fedora14 guest with debug turned on.
by , 14 years ago
Attachment: | hoeferbe_Fedora14_guest_Xorg.0.log added |
---|
Xorg.0.log file from my Fedora 14 guest.
comment:25 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Summary: | Segfault in swrast.c:get_window_size() (vboxvideo) in Fedora 13 when accessing 3d tools → 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).
Virtualbox Log file