Re: [PyOpenGL-Users] access violation when calling glGenFramebuffers

[Mike C. F. <mcf...@vr...>]

On 13-04-04 11:55 AM, Chris Barker - NOAA Federal wrote:
> On Wed, Apr 3, 2013 at 10:24 AM, Cyrille Rossant
> <cyr...@gm...> wrote:
...
> well, that is a bigger-than-32bit address -- I suppose it's possible
> that this is a 32/64 bit issue.
>
> Can you test it with 32 bit python? Even if you don't want to
> ultimatley go that route, it may give you a hint.
>
> Also, from teh ctypes docs:
>
> c_uint	is a unsigned int
>
> you may have some issues there, an "int" is a really poorly defined
> type, and depending on the compiler, it may be 32 bits on 32bit
> systems, and 32 or 64 bit on 64 bit systems (and the MS compilers and
> gnu do it differently), so there couldn be some mis-match there.
>
> It's beyond me that C has survived this long with such soft defining
> of type sizes! Here's hoping that people start using the C99 defined
> size integer types sooner than later...
>
> (though from the looks of it, ctypes doesn't support those either...)
Actually ctypes *does* now support sized types:

     ctypes.c_int8 ctypes.c_int16 ctypes.c_int32 ctypes.c_int64

(this is on python 2.7.3 Linux 64-bit).  I actually am using them while 
working on the EGL wrapper, and will likely switch to using them on the 
GL level too (since e.g. GLint is explicitly 32-bit, *not* platform 
specific).
.
     ctypes.c_size_t

is also pretty useful, and I will likely use that as appropriate.

As for the original error, it *could* be that there's a problem with 
64-bit windows there, but I'm a bit skeptical, as 64-bit Linux doesn't 
show any problems, and the test_core.py script actually generates a 
framebuffer during testing if glGenFrameBuffers is available.  That's my 
very first smoke-test for the build working on any platform.

Something to verify to debug the issue:

  * the address printed out as the access violation is *precisely* the
    same as the result of ctypes.addressof( variable ) when doing the
    raw API query

if we're looking at different values, then we likely have the wrapper 
wrong (i.e. somehow it is changing the value passed in), if they are the 
same, then there's something preventing the writing to that address... 
which I don't have much to contribute...

HTH,
Mike