VM crash in GL11.nglDrawArrays()

[Marvin Fröhlich]

I get a VM crash in GL11.nglDrawArrays(). It is not happening always. It happens sometimes and sometimes not for the very same testcase. So I cannot say, if it is anything in my code (the Xith3D code). Here is the VM dump file. I hope it helps you.

Is there anything, that I should not pass to the glDrawArrays() function? Though at least there should not be a VM crash, but a clean Java exception, right? So even, if I am doing something wrong, this is a bug because of that. I am very sure, that it is not a problem of wrong threading.

I am using LWJGL 1.1.3.

Chees and thanks.

Marvin

PS: btw. the upload folder is full. So here is the file.

[Riven]

This might happen when you
   glEnable NORMAL_ARRAY (or another component type)
but never set the pointer.


Further, your indices could be plain wrong, but that's almost too obvious.

You could write a little checker that... checks it.

[Marvin Fröhlich]

This might happen when you
   glEnable NORMAL_ARRAY (or another component type)
but never set the pointer.

Thanks. I will check that.

Further, your indices could be plain wrong, but that's almost too obvious.

You could write a little checker that... checks it.

By plane-wrong you mean, that they point to different sides for different polygons of the same vertex-array, right? what's the problem with this?

Marvin

Games published by our own members! Check 'em out!

[Marvin Fröhlich]

This might happen when you
   glEnable NORMAL_ARRAY (or another component type)
but never set the pointer.

I have checked that. And it is definitely not correct in my code. I explicitly call glDisableClientState( ... ) for each geometry feature, that is not currently used.

The strange thing is, that the crash doesn't happen always, but only occasionally.

Marvin

[Riven]

With plain-wrong (not plane-wrong) I meant the indices that would yield an OutOfBoundsException when used in Java: as in negative offsets, or simply offset+index >= max vertex

[Marvin Fröhlich]

With plain-wrong (not plane-wrong)...

Oops .

...I meant the indices that would yield an OutOfBoundsException when used in Java: as in negative offsets, or simply offset+index >= max vertex

Well, this would mean, that the crash would happen always, since the geometry data is not altered an any way in this particular testcase, wouldn't it?

Marvin

[Riven]

Nope, there can be 'valid' data in the memory-region after the 'real' data.



Anyway, in such cases: narrow it down.
Are the expected parameters those that you specify? Are you indices pointing at byte-offsets, float-offset, element-offsets or component-offsets?

Do some tests to see whether it works with 3 triangles, exactly how you'd expect it to work.


I don't know how much experience you have, so I don't want to insult you with this remarks...

[Marvin Fröhlich]

Nope, there can be 'valid' data in the memory-region after the 'real' data.

Anyway, in such cases: narrow it down.
Are the expected parameters those that you specify? Are you indices pointing at byte-offsets, float-offset, element-offsets or component-offsets?

Do some tests to see whether it works with 3 triangles, exactly how you'd expect it to work.

I don't know how much experience you have, so I don't want to insult you with this remarks...

Well, I am not that unexperienced. But it looks like this is going beyond my knowledge. Actually, that's why I'm posting here . But I will try to have a look at the offset-type thing. The valid data behind real data thing should not be a problem here, since the scene is absolutely static.

Marvin

[elias]

The wonderful thing about native code is that often behaviour is 'undefined', which means anything can happen If you're using VBOs try without them. If you're getting a random crash with static data, you can still be running foul of invalid indices, where there's some valid data after your buffers which are freed by a garbage collect, free() or whatnot. For example, we had a crash a while ago that was caused by a nio buffer set up with glVertexPointer were subsequently freed by the garbage collector. We implemented a feture in lwjgl that kept the buffer references around, but that code might be broken in subtle ways. So I'd keep carefully bisecting my way towards the bug, if it's even in code controlled by you at all.

 - elias

[Marvin Fröhlich]

Just to give this thread a finishing: The problems seems to have been related to some texture-coordinates states, that I didn't reset, when not used in the next shape.

Thanks a lot for all your replies and help.

Marvin