Crash on Virtualbox

[David Griffin]

CURRENT WORKAROUND:

To get Sprites working under VirtualBox, add the following two lines to your code just after import.

from PyGL3Display.twodspriteinfrastructure import SpriteCommon
SpriteCommon.maxTextureSize = 1024

Original Bug report

Alan Bourke (alanpbourke) wrote 23 minutes ago:

I'm getting this too, on the latest trunk as of today (68). A couple of samples like the 'lines' one run OK but criticalMass, for example, throws a similar error to the above.

Ubuntu 12.04 in a Virtualbox VM.

Traceback:

OpenGL Warning: vboxCall failed with VBox status code -54

OpenGL Warning: SHCRGL_GUEST_FN_WRITE_READ (67108924) failed with 0 fffffffe

OpenGL Warning: vboxCall failed with VBox status code -54

OpenGL Warning: SHCRGL_GUEST_FN_WRITE_READ (67108924) failed with 0 fffffffe

Traceback (most recent call last):
  File "/home/alanb/Aptana Studio 3 Workspace/PyGL3Display/examples/criticalMass.py", line 169, in <module>
    main()
  File "/home/alanb/Aptana Studio 3 Workspace/PyGL3Display/examples/criticalMass.py", line 151, in main
    x = Level(10, (400,400))
  File "/home/alanb/Aptana Studio 3 Workspace/PyGL3Display/examples/criticalMass.py", line 123, in __init__
    self.ballImg = loadImage('ball.png')
  File "../PyGL3Display/pygameimages.py", line 80, in loadImage
    return cls.surfaceify(pygame.image.load(*args, **kwargs))
  File "../PyGL3Display/pygameimages.py", line 89, in surfaceify
    ret.upload(pygameSurface)
  File "../PyGL3Display/pygameimages.py", line 75, in upload
    Image.upload(self, self.rawimage)
  File "../PyGL3Display/twodspriteinfrastructure.py", line 468, in upload
    self.atlas.uploadToBox(image, self.redrawData)
  File "../PyGL3Display/twodspriteinfrastructure.py", line 428, in uploadToBox
    GL_RGBA, GL_UNSIGNED_BYTE, data)
  File "/usr/lib/pymodules/python2.7/OpenGL/latebind.py", line 45, in __call__
    return self._finalCall( *args, **named )
  File "/usr/lib/pymodules/python2.7/OpenGL/wrapper.py", line 791, in wrapperCall
    raise err
OpenGL.error.GLError: GLError(
 err = 1282,
 description = 'invalid operation',
 baseOperation = glTexSubImage2D,
 pyArgs = (
  GL_TEXTURE_2D,
  0,
  0,
  0,
  100,
  100,
  GL_RGBA,
  GL_UNSIGNED_BYTE,
  '\xff\xff\xff\x00\xff\xff\xff\x00\xff...,
 ),
 cArgs = (
  GL_TEXTURE_2D,
  0,
  0,
  0,
  100,
  100,
  GL_RGBA,
  GL_UNSIGNED_BYTE,
  '\xff\xff\xff\x00\xff\xff\xff\x00\xff...,
 ),
 cArguments = (
  GL_TEXTURE_2D,
  0,
  0,
  0,
  100,
  100,
  GL_RGBA,
  GL_UNSIGNED_BYTE,
  '\xff\xff\xff\x00\xff\xff\xff\x00\xff...,
 )
)

[David Griffin (habilain)]

I've done a bit of searching on the bug, and it seems that the error message SHCRGL_GUEST_FN_WRITE_READ is the telling factor. I'm a bit in the dark as the Virtualbox website is timing out on me, but this seems to be related to bugs in OpenGL on VirtualBox VMs.

Specifically, it seems that Virtualbox is allowing a texture to be created that is too big for it to use, and then crashing when it is used. It is also passing off all the checks that a developer is supposed to use to determine maximum texture size, and still crashing.

Just to confirm: the examples that work should be lines, ellipses, triangles - all others should crash (as they use textures).

Also: do these crashes happen outside a Virtualbox VM?

[Alan Bourke (alanpbourke)]

I tested on a Windows 7 64-bit machine. First off it was throwing loads of errors against Python 3.x and the relevant PyGame version, so I tried it against Python 2.6.6 and the PyGame version for that.

The criticalMass sample and others like the platformer work, but the GLUT one doesn't, probably due to the OpenGL drivers, nor do a couple of others, but the problems there are Python syntax related.

Fast, by gum.

[David Griffin (habilain)]

Python 3 compatibility is Bug #966796; it's a known issue, and is tricky to fix as (at least parts of) PyOpenGL do not work under Python 3.

So to try and organise:

The bug that this report is about crashes in Virtualbox - and these crashes don't appear on the same machine normally. It'll get properly investigated once I have the time to set up a Virtualbox'd machine.

On the GLUT example: seems I've accidentally deleted an import, and so it wasn't working for anyone. Fixed in trunk r70. However, the GLUT example is pretty bad in general (i.e. no input handling at all), so I've filed Bug #992230 on it.

[Alan Bourke (alanpbourke)]

FWIW, in #2 it was a different machine running Win 7 natively. I have just re-tested on a Windows 7 VM on the same host PC/Virtualbox as the Ubuntu VM in the original post, because Virtualbox doesn't support 2D acceleration for Linux guest, but does for Windows guests. Same sort of error though:

Traceback (most recent call last):
  File "C:\Users\alan\Aptana Studio 3 Workspace\PyGL3Display\examples\criticalMass.py", line 169, in <module>
    main()
  File "C:\Users\alan\Aptana Studio 3 Workspace\PyGL3Display\examples\criticalMass.py", line 151, in main
    x = Level(10, (400,400))
  File "C:\Users\alan\Aptana Studio 3 Workspace\PyGL3Display\examples\criticalMass.py", line 123, in __init__
    self.ballImg = loadImage('ball.png')
  File "..\PyGL3Display\pygameimages.py", line 80, in loadImage
    return cls.surfaceify(pygame.image.load(*args, **kwargs))
  File "..\PyGL3Display\pygameimages.py", line 89, in surfaceify
    ret.upload(pygameSurface)
  File "..\PyGL3Display\pygameimages.py", line 75, in upload
    Image.upload(self, self.rawimage)
  File "..\PyGL3Display\twodspriteinfrastructure.py", line 479, in upload
    self.atlas.uploadToBox(image, self.redrawData)
  File "..\PyGL3Display\twodspriteinfrastructure.py", line 437, in uploadToBox
    GL_RGBA, GL_UNSIGNED_BYTE, data)
  File "latebind.pyx", line 32, in OpenGL_accelerate.latebind.LateBind.__call__ (src\latebind.c:559)
  File "wrapper.pyx", line 315, in OpenGL_accelerate.wrapper.Wrapper.__call__ (src\wrapper.c:5196)
OpenGL.error.GLErrorOpenGL Warning: VBoxCrHgsmiCreate failed
: GLError(
 err = 1282,
 description = 'invalid operation',
 baseOperation = glTexSubImage2D,
 pyArgs = (
  GL_TEXTURE_2D,
  0,
  0,
  0,
  100,
  100,
  GL_RGBA,
  GL_UNSIGNED_BYTE,
  '\xff\xff\xff\x00\xff\xff\xff\x00\xff...,
 ),
 cArgs = (
  GL_TEXTURE_2D,
  0,
  0,
  0,
  100,
  100,
  GL_RGBA,
  GL_UNSIGNED_BYTE,
  '\xff\xff\xff\x00\xff\xff\xff\x00\xff...,
 ),
 cArguments = (
  GL_TEXTURE_2D,
  0,
  0,
  0,
  100,
  100,
  GL_RGBA,
  GL_UNSIGNED_BYTE,
  '\xff\xff\xff\x00\xff\xff\xff\x00\xff...,
 )
)
OpenGL Warning: VBoxCrHgsmiCreate failed
OpenGL Warning: VBoxCrHgsmiCreate failed

[David Griffin (habilain)]

A ref to what I believe is a bug report on VirtualBox: https://www.virtualbox.org/ticket/5720. Also a note: some people say this can be caused by old versions of the guest additions software (i.e. when upgrading VMs from older versions of VirtualBox).

Anyhow, hopefully this weekend I'll be able to investigate this further. However, if it turns out that PyGL3Display is doing everything it can to determine proper texture size and VirtualBox is giving improper results to these calls, this will probably be marked as a WONTFIX.

Well, that or perhaps a configurable option somewhere that might be able to work around the problem...

[Alan Bourke (alanpbourke)]

I'd imagine it's totally a VirtualBox issue and would be doubtful that you could work around it - it was really just to flag it up some the info was out there.

[David Griffin (habilain)]

Partial fix released. The main bug is definitely in the VirtualBox accelerated driver allowing a texture to be created which it cannot use. However, now if you want to use texturing on VirtualBox there is a switch to lower the maximum size of texture created, and this bypasses the bug. It isn't being enabled by default as it degrades performance on compliant systems. However, adding the following lines of code just after imports will fix the problem

from PyGL3Display.twodspriteinfrastructure import SpriteCommon
SpriteCommon.maxTextureSize = 1024

Note that it's possible the location of this switch may change, but if that happens it'll be documented properly.

[David Griffin (habilain)]

And by fix released, I mean committed in revision 71.

[Alan Bourke (alanpbourke)]

Marvellous, thanks.

[David Griffin (habilain)]

Fix released in 1.9-alpha7; looking at possibility of creating a "buggy drivers" file that automates the fix.

[David Griffin (habilain)]

Now implemented a hacks file that automatically applies this hack when necessary. Found in latest trunk, and will be in next release.