Re: [PyOpenGL-Users] access violation when calling glGenFramebuffers
Brought to you by:
mcfletch
From: Patrick D. <pyo...@pd...> - 2013-04-08 08:11:50
|
Am 06.04.2013 22:26, schrieb Mike C. Fletcher: > On 13-04-06 11:55 AM, Patrick Dietrich wrote: > ... >> OK here is what I did: >> >> - uninstalled PyOpenGL_accelerate and PyOpenGL (using Windows >> Software-Removal) >> - downloaded PyOpenGL from bzr: "bzr branch lp:pyopengl" >> - built and installed PyOpenGL: "python setup.py build", "python >> setup.py install" >> - downloaded 64-bit pygame 1.9.2pre from >> http://www.lfd.uci.edu/~gohlke/pythonlibs/#pygame >> - executed "python test_core.py" in the test/ directory inside the >> pyopengl directory from bzr >> --> this fails (see attachment) >> >> I'm not sure if I have to change to the "head" distro somehow. Sorry >> I'm not familiar with bzr. > Nope, that's head already. >> I also tried to test my drivers with a simple C-Program. Unfortunately >> I can't get glew running with MinGW. But from what I read in the >> conversation MinGW may yield different results that MSVC anyway? > It would tell us if it's hardware/drivers. > > I followed the same steps, and on an Intel Graphics Win64 Windows 7 > machine this time... and got 0 errors for the test_core test suite (on > bzr head). The values you're seeing in the access violation reports > *look* wrong, that is, the first 4 bytes are all 1's. If you could > print out: > > v = ctypes.c_uint() > print ctypes.addressof( v ) > > for a value that's producing the error, it would at least let us know if > the address is wrong before it goes into the wrapping process. If the > all-ones addresses are "real", then maybe we're seeing a driver issue > with the greater than 2GB addresses (maybe drivers coded for 32-bit > mode?) If they are an artefact of the conversion process, then we can > use pdb to step through the wrapping process one step at a time to try > to figure out where the conversion gets messed up. > > Take care, > Mike > So here is the code I tested: print 'ctypes.addressof( OpenGL.raw.GL.EXT.framebuffer_object.glGenFramebuffersEXT ): %X' % ctypes.addressof( OpenGL.raw.GL.EXT.framebuffer_object.glGenFramebuffersEXT ) fbo = ctypes.c_uint(1) print 'ctypes.addressof(fbo): %X' % ctypes.addressof(fbo) one = ctypes.c_int(1) OpenGL.raw.GL.EXT.framebuffer_object.glGenFramebuffersEXT(one, ctypes.byref(fbo)) And this is the correspoinding output: ctypes.addressof( OpenGL.raw.GL.EXT.framebuffer_object.glGenFramebuffersEXT ): 7E7C710 ctypes.addressof(fbo): 7E98F10 Traceback (most recent call last): File "C:\Users\Patrick\Dev\PCT\open_gl_widgets.py", line 315, in OnPaint self.main_canvas = CanvasLayer( self.viewport_width, self.viewport_height ) File "C:\Users\Patrick\Dev\PCT\open_gl_widgets.py", line 205, in __init__ OpenGL.raw.GL.EXT.framebuffer_object.glGenFramebuffersEXT(one, ctypes.byref(fbo)) WindowsError: exception: access violation writing 0xFFFFFFFFEBAFA790 It seems to me that something goes wrong in the native routines. Could this be a bug when fetching the routines? Cheers, Patrick PS: Some things I tested for my system: >>> v = ctypes.c_uint() >>> ctypes.addressof( v ) 37067024L >>> ctypes.c_size_t() c_ulonglong(0L) >>> ctypes.c_uint() c_ulong(0L) >>> ctypes.c_int() c_long(0) >>> ctypes.c_uint32() c_ulong(0L) >>> ctypes.c_int32() c_long(0) >>> ctypes.c_uint64() c_ulonglong(0L) >>> ctypes.c_int64() c_longlong(0L) >>> |