gl calls failing with malloc errors

[Mushrooms]

glGetShaderInfoLog and glGetProgramInfoLog were giving me the error "malloc: no size given".

I've traced the issue to problems in gl.spec.FIXED. Here is an example of a bad spec. The "infoLog" param specifies "length" when it should be using "bufSize":

...
GetShaderInfoLog(shader, bufSize, length, infoLog)
return void
param shader UInt32 in value
param bufSize SizeI in value
param length SizeI out array [1]
param infoLog Char out array [length]
category VERSION_2_0
dlflags notlistable
version 2.0
extension
glxsingle ?
glxflags ignore
offset ?
...

There are several other functions with similar problems.

[Stephan Houben]

Hi,
I know the specfiles are very buggy.
This is quite frustrating. Stuff which isn't checked by a C compiler (such as array bounds)
is often broken. Bug reports to Khronos on this appear to be redirected to /dev/null .

Anyway, do you happen to have a fixed verison which I could pull?

Thanks,

Stephan

[Mushrooms]

Thank you for the prompt response! It's too bad Khronos doesn't seem to care. I'd love to help work on OpenGL bindings for Racket. I've already tried sgl and sgl/gl but they're missing shader functions, so I came here. Perhaps once this is working and tested it can replace sgl/gl in the main distribution?

I started going through gl.spec.FIXED looking for instances of "out array" and fixing them, then I remembered a strange behavior I had writing my program and realized this is gonna be a lot hairier than I thought. glGet* functions are typically supposed to write a value at the pointer passed to them. I'm pretty sure these should be pointers to a single value, but the spec gives them types such as:

Int32 out array [COMPSIZE(pname)]

It seems that this specifies an array with a length of the value of an enumerator. That explains the strange behavior I had, where I got a vector of 30000-something with the desired value in the first element when calling one of these functions. I'd love to fix this too while I'm at it, only I don't know what COMPSIZE does and it might be important because it's used in a lot of suspicious places. Do you know what it is? And what does it mean when its arguments are separated with a slash, as in:

param    pixels    Void in array [COMPSIZE(format/type/width/height/depth)]

[Stephan Houben]

Hi sf17k,

On 02/21/2012 06:53 PM, sf17k wrote:

So here's what happened. I started going through gl.spec.FIXED looking
for instances of "out array" and fixing them, then I remembered a
strange behavior I had writing my program and realized this is gonna
be a lot hairier than I thought. glGet* functions are typically
supposed to write a value at the pointer passed to them. I'm pretty
sure these should be pointers to a single value, but the spec gives
them types such as:

Int32 out array [COMPSIZE(pname)]

This means it is an output array (i.e. filled by the GL function) of Int32's
and that the length is somehow dependent on the parameter "pname".

For the glGet* family of functions the actual size of the vector is listed
in specfiles/enum.spec for each enum. During parsing of the specfiles a
hash table pname-map is constructed which maps each enum to the associated
vector size, so that the Racket binding can directly allocate and return a vector
of the correct size.

Unfortunately it seems that not all possible glGet values have an appropriate
vector length declared (especially the more recent ones).
Are you running into one which is missing in particular?

It seems that this specifies an array with a length of the value of
an enumerator. That explains the strange behavior I had, where I got
a vector of 30000-something with the desired value in the first
element when calling one of these functions. I'd love to fix this too
while I'm at it, only I don't know what COMPSIZE does and it might be
important because it's used in a lot of suspicious places. Do you know
what it is? And what does it mean when its arguments are separated
with a slash, as in:

param pixels Void in array [COMPSIZE(format/type/width/height/depth)]

So in general COMPSIZE simply means "the size is computed somehow from
the following arguments". It doesn't specify how.
The readspec.rkt understand only the special case "COMPSIZE(pname)" which translates
into a lookup of pname-map as explained above.

The issue you are running into might be that in certain cases the spec contains simply
"pname" where apparently "COMPSIZE(pname)" was intended.
Unfortunately replacing these with COMPSIZE(pname) might not be so useful since it appears
that for these functions, the appropriate enums are also missing a size annotation.

The best solution is probably the following:
I replace all occurrences of [pname] with [*], which is not a valid length expression for readspec.rkt .
Then readspec.rkt will generate bindings which require an explicit vector to be passed in
(of the correct length, as determined from the docs) which is less convenient but
has the distinct advantage that it can be actually made to work.

Stephan Houben

[Mushrooms]

The issue you are running into might be that in certain cases the spec contains simply "pname" where apparently "COMPSIZE(pname)" was intended.

Ah, you're right. That's exactly the case with the functions I tried, glGetShaderiv and glGetProgramiv. My mistake not noticing at first.