#314 closed enhancement (worksforme)
VirtualBox win32 clients can crash hard just doing the initial OpenGL probing
Reported by: | Antoine Martin | Owned by: | Antoine Martin |
---|---|---|---|
Priority: | major | Milestone: | 0.14 |
Component: | client | Version: | 0.14.x |
Keywords: | Cc: |
Description (last modified by )
When we start the application without specifying "--opengl=no
" (or via the config file equivallent: opengl=no
), the xpra.gl.gl_check class does some driver probing to see if the system's OpenGL
driver is up to the task, checking:
- availability of
OpenGL
andpygtkglext
modules GL_VERSION
at least 1.1- checks the driver properties against our blacklist: we simply refuse to work with the "nouveau" Linux driver (too buggy) and "Humper" (the driver in
VirtualBox
- also buggy, but worse!) - then some other irrelevant checks.. (required extensions, etc - it does not get that far unfortunately)
I was hoping that blacklisting "Humper" (done as part of r3006) would be enough to prevent the hard VM crashes that I had been seeing, unfortunately that was not the case.
So in r3073, we try to detect if we are running in VirtualBox
, and if so we set the default for the opengl
option to False
, this prevents the driver probing and avoids the crashes.
The (unavoidable?) problem with this approach is that if and when VirtualBox
fix the driver issue, we will still end up ignoring it and OpenGL
will remain disabled.. Unless we can somehow load the driver version from the DLL and detect the versions that do work?
Interestingly, running the OpenGL_test.exe
command, which is installed as part of xpra and runs the exact same code, does not seem to be able to crash the VM - though I did get this error instead (you have to run it many many times to hit errors):
- this in stdout:
OpenGL Warning: SHCRGL_GUEST_FN_WRITE_READ (28) failed with ffffffdb ffffffea
- and an alert:
The instruction at "0x05451a1f" referenced memory at "0x00000008". The memory could not be "read".
Looks like a bad pointer somewhere. Note: I reproduced the exact same values above twice..
- Also seeing this message when closing the application - but I think this one may well be a separate issue:
OpenGL Warning: Assertion failed: ctx>fAutoFlush, \ file D:\tinderbox\add-4.2\src\VBox\Additions\common\crOpenGL\pack\packspu_misc.c, line 648
The VBox
Additions
source can be found here, this assertion is in packspu_VBoxDetachThread
:
for (i=0; i<CR_MAX_CONTEXTS; ++i) { ContextInfo *ctx = &pack_spu.context[i]; if (ctx->currentThread == thread) { CRASSERT(ctx->fAutoFlush); ctx->currentThread = NULL; } }
Looks like it expects fAutoFlush
to be true because the thread matches.
Maybe when we cleanup we end up closing the window from the wrong thread.
AFAICT, this happens with all versions of VirtualBox
, up to and including 4.2.12
This happens with both an nvidia host driver and radeon, here are the log contents:
00:00:16.643984 Display::handleDisplayResize(): uScreenId = 0, pvVRAM=00007fbf1c000000 w=1378 h=1050 bpp=24 cbLine=0x1028, flags=0 x1 00:00:16.687557 2D video acceleration is enabled. 00:00:21.642813 PCNet#0: The link is back up again after the restore. 03:59:02.713599 Switching Gl mode on 03:59:02.886585 OpenGL Info: Render SPU: GL_VENDOR: ATI Technologies Inc. 03:59:02.886692 OpenGL Info: Render SPU: GL_RENDERER: ATI Radeon HD 5450 03:59:02.886716 OpenGL Info: Render SPU: GL_VERSION: 4.2.12002 Compatibility Profile Context 9.002 03:59:02.886770 OpenGL Info: Render SPU: GL_EXTENSIONS: GL_AMDX_debug_output (...) 03:59:22.734485 Switching Gl mode off 04:00:14.899835 Switching Gl mode on
Absolutely nothing when it crashes, and nothing on the host's "dmesg" either. Now running with gdb attached to see if I can get a backtrace.
Probably unrelated, but I am also seeing these errors after closing a window:
2013-04-16 10:29:30,894 OpenGL paint error: GLError( err = 1282, description = 'invalid operation', baseOperation = glEnd, cArguments = () ) Traceback (most recent call last): File "xpra\gl\gl_window_backing.pyc", line 210, in do_gl_paint File "xpra\gl\gl_window_backing.pyc", line 309, in render_image File "latebind.pyx", line 44, in OpenGL_accelerate.latebind.Curry.__call__ (src\latebind.c:832) File "C:\Program Files\Xpra\OpenGL\GL\exceptional.py", line 57, in glEnd File "errorchecker.pyx", line 50, in OpenGL_accelerate.errorchecker._ErrorChecker.glCheckError (src\errorchecker.c:854 )
Finally a link to virtual box "opengl crash" bugs - and there are quite a few, seemingly related:
Also it seems that some bugs require the VM to be suspended then resumed to trigger. Indeed, vbox failed to suspend my VM if an opengl window was active when I suspended it..
Change History (11)
comment:1 Changed 8 years ago by
Description: | modified (diff) |
---|---|
Owner: | changed from Antoine Martin to Antoine Martin |
Status: | new → assigned |
comment:2 Changed 8 years ago by
Description: | modified (diff) |
---|
comment:3 Changed 8 years ago by
Description: | modified (diff) |
---|
comment:4 Changed 8 years ago by
Description: | modified (diff) |
---|
comment:5 Changed 8 years ago by
Description: | modified (diff) |
---|
comment:6 Changed 7 years ago by
Resolution: | → worksforme |
---|---|
Status: | assigned → closed |
comment:7 Changed 6 years ago by
FWIW: I've been running XP in the latest virtualbox with opengl enabled, works very well... I wished there was a way to detect if it is safe to use.
comment:8 Changed 5 years ago by
Note: in 0.16.0, we allow opengl to be enabled with virtualbox guests, it just starts disabled by default (except with Ubuntu 12.04 where we just don't allow it at all - as it is just too buggy)
comment:10 Changed 14 months ago by
Milestone: | future → 0.14 |
---|
comment:11 Changed 3 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/314
Newer versions of virtualbox have improved a lot, they no longer crash when probing and no longer get blacklisted.
I think we're doing enough to workaround problems that aren't really ours to solve. Closing.