Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (538)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (600)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  VM crash in GL11.nglDrawArrays()  (Read 2963 times)
0 Members and 1 Guest are viewing this topic.
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Posted 2007-12-19 19:55:31 »

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.
Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 840
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #1 - Posted 2007-12-19 21:23:01 »

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.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #2 - Posted 2007-12-19 22:15:48 »

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!
Legends of Yore - The Casual Retro Roguelike
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #3 - Posted 2007-12-19 22:35:07 »

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
Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 840
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #4 - Posted 2007-12-19 22:36:06 »

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

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #5 - Posted 2007-12-19 23:24:02 »

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

Oops Smiley.

...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
Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 840
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #6 - Posted 2007-12-20 00:42:21 »

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... Smiley

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #7 - Posted 2007-12-20 18:34:32 »

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... Smiley

Well, I am not that unexperienced. But it looks like this is going beyond my knowledge. Actually, that's why I'm posting here Wink. 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
Offline elias

Senior Devvie





« Reply #8 - Posted 2007-12-20 21:12:07 »

The wonderful thing about native code is that often behaviour is 'undefined', which means anything can happen Smiley 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

Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #9 - Posted 2007-12-26 15:10:57 »

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
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

rwatson462 (28 views)
2014-12-15 09:26:44

Mr.CodeIt (19 views)
2014-12-14 19:50:38

BurntPizza (35 views)
2014-12-09 22:41:13

BurntPizza (70 views)
2014-12-08 04:46:31

JscottyBieshaar (32 views)
2014-12-05 12:39:02

SHC (44 views)
2014-12-03 16:27:13

CopyableCougar4 (40 views)
2014-11-29 21:32:03

toopeicgaming1999 (108 views)
2014-11-26 15:22:04

toopeicgaming1999 (94 views)
2014-11-26 15:20:36

toopeicgaming1999 (29 views)
2014-11-26 15:20:08
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!