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.

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.

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.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org