Re: access violation when calling glGenFramebuffers

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)
 >>>


------------------------------------------------------------------------------
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
_______________________________________________
PyOpenGL Homepage
http://pyopengl.sourceforge.net