VM crash in GL11.nglDrawArrays()

OpenGL Development
#1

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.

#2

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.

#3

Thanks. I will check that.

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

#4

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

#5

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

#6

Oops :).

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

#7

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… :slight_smile:

#8

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

#9

The wonderful thing about native code is that often behaviour is ‘undefined’, which means anything can happen :slight_smile: 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
#10

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