Jogl, AWT, JVM Crash

General Discussions
#1

Hey,

I did a quick search on the forums for problems with JOGL and JVM crashes, and found a lot of questions related to the subject. I’m about to start investigating our own Jogl / AWT related JVM crash and I was hoping that I could get some advice on where to start.

The crash frequency is directly related to input on AWT. So far it has only happened during mouse movement on screen. It is indirectly related to the amount of rendering we are doing in our engine – the more rendering we are doing on screen the greater the frequency of the crashes that occur.

We are using immediate mode for just about everything at the moment – we are drawing textured quads, text, and lines to the screen. I’ve updated to the latest JDK (1.6 update 21), and I’ve made sure that I have the correct jogl dlls (Amd x64).

Specs:
AMD Athalon II x4 630 Processor
ATI Radeon HD 5700 Series

The beginning of the crash log:
--------------- T H R E A D ---------------

Current thread (0x000000004ba77800): JavaThread “CompilerThread0” daemon [_thread_in_native, id=4040, stack(0x000000004be20000,0x000000004bf20000)]

siginfo: ExceptionCode=0xc0000005, reading address 0xffffffffffffffff

Registers:
EAX=0x000000006d8c7470, EBX=0x0000000000000000, ECX=0x000000006dd7adb0, EDX=0x000000006dd7adb0
ESP=0x000000004bf1cc40, EBP=0x000000004bc09140, ESI=0x000000005338bd70, EDI=0x000000005338c030
EIP=0x000000006dbea343, EFLAGS=0x0000000000010217

Top of Stack: (sp=0x000000004bf1cc40)
0x000000004bf1cc40: 000000004bf1cd30 000000006d8dba20
0x000000004bf1cc50: 000000004bf1cc80 0000000000000000
0x000000004bf1cc60: 000000004bf1f290 000000006da33b0a
0x000000004bf1cc70: 000000004bf1ce68 000000000000025c
0x000000004bf1cc80: ffffffffffffffff 0000000053472f00
0x000000004bf1cc90: 000000004bf1d000 000000006d8f7b8b
0x000000004bf1cca0: 0000000000008080 000000006d8eca33
0x000000004bf1ccb0: 0000000000000003 000000006d8ed160
0x000000004bf1ccc0: 000000004bc09040 000000006dbea4ec
0x000000004bf1ccd0: 0000000054cfead0 000000004bf1f3b8
0x000000004bf1cce0: 0000000000000003 000000006dc35759
0x000000004bf1ccf0: 000000005338bbd0 000000006dc34dce
0x000000004bf1cd00: 0000000000000004 000000004bc08fc0
0x000000004bf1cd10: 00000000548b5fe0 000000006dbea4ec
0x000000004bf1cd20: 0000000000000001 000000006da32855
0x000000004bf1cd30: 00000000532b2ef8 000000004bf1cfc8

Instructions: (pc=0x000000006dbea343)
0x000000006dbea333: 00 48 83 c4 20 5b c3 48 83 f9 ff 74 6d 48 8b 01
0x000000006dbea343: ff 50 28 38 1d bc 9e 2c 00 48 8b c8 74 23 39 1d

Stack: [0x000000004be20000,0x000000004bf20000], sp=0x000000004bf1cc40, free space=3f30000000000000000k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [jvm.dll+0x35a343]

Current CompileTask:
C2:629 com.novel.tech1.client.physics.CollisionLibrary.checkCollision(Lcom/novel/tech1/client/physics/Collidable;Lcom/novel/tech1/client/math/Matrix4;Lcom/novel/tech1/client/math/Matrix4;Lcom/novel/tech1/client/physics/Collidable;Lcom/novel/tech1/client/math/Matrix4;Lcom/novel/tech1/client/math/Matrix4;Lcom/novel/tech1/client/physics/ContactInfo_t;)I (1426 bytes)

Any advice on where to get started figuring this out would be greatly appreciated, this issue has been plaguing our development process for a while now.

Thanks a ton!!

#2

I have already used JOGL on 64-bits machines under Windows without such problems.

Do you make the context current or do you release it explicitly sometimes? Do you call JOGL directly in a mouse (motion) listener?

#3

We finally ‘resolved’ this issue. It turns out that switching to a 32-bit JVM and i586 dlls fixed all of our problems. I went in with an opengl debugger and could find absolutely nothing out of the ordinary with our opengl states at the time of the crashes. Should I be filing a bug somewhere?

For those of you that are interested, here is the repro that worked on every 64 bit machine in our office:

  1. Install a 64-bit jvm
  2. Install the 64 bit dlls (http://download.java.net/media/jogl/builds/archive/jsr-231-1.1.1a/jogl-1.1.1a-windows-amd64.zip)
  3. Draw enough to the screen that your machine is stressed to sub 60 fps.
  4. Flood awt with mouse input.

The crash on our machines reliably happened in under a minute, usually within a few seconds. If anyone else can repro using these steps I’ll try to figure out how to file a bug.

== EDIT ==
I forgot to mention, a key step to reproing this reliably for us was having more than one client up. so a step 3.1 in the repro would be: “Start up multiple instances of your app”

#4

JOGL 1.1.1a is no more maintained, you have to switch to JOGL 2 that adresses the problem of multiple displays for example. If you reproduce your bug with JOGL 2, then I will advise you to write a bug report.