how do you deal with Java native crashes?

Newbie & Debugging Questions
#1

Hi,

While I have been programming in Java for many years now, java native crashes are a new animal to me.

I have had to deal with them when using the JOGL and Odejava native API’s over the last year, but in all cases they were bugs in the API - and in the case of Odejava, the java native crash was pretty useful in actually locating the problem within the native library and fixing it.

I currently have a problem described in this thread.
where Java’s crashing (the errors occure in the main java libraries - not the third party ones) and I can’t work out why. Is it Odejava causing it to crash? Or what? The stack traces are all but useless and I have had to go back to log statements to try and work out where the errors are. Then it seemed like my log statements were causing the crashing (it would work when I removed them).

I’m out of ideas.

Am I looking at a bug in Java here? If so what do I need to do to submit a bug - I’m not convinced I can create a small test case here and I’m not convinced it’s not Odejava somehow causing the problems.

If you can offer specific advice to my problem - please reply to the other thread I posted. but general ‘dealing with native crashes advice’ would be great too.

Thanks in advance,

Will.

#2

Memory trashing can cause a native crash when the garbage collector is called. The stack trace will be useless, as it will only show what caused the gc to kick in. Not where the memory was trashed. You can recognize it by the native function wich called something with “heap”.

#3

thanks for the tip.

So allocating more memory to the heap may be a work around?

Here’s the two dumps I get - see anything interesting in them?


An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 11 occurred at PC=0x400AD730
Function=(null)+0x400AD730
Library=/lib/tls/libc.so.6
 
NOTE: We are unable to locate the function name symbol for the error
      just occurred. Please refer to release documentation for possible
      reason and solutions.
 
 
Current Java thread:
        at org.odejava.xode.XODEGeom.<init>(XODEGeom.java:90)
        at org.odejava.xode.XODEGroup.parseGroupChild(XODEGroup.java:126)
        at org.odejava.xode.XODEBody.<init>(XODEBody.java:89)
        at org.odejava.xode.XODEGroup.parseGroupChild(XODEGroup.java:122)
        at org.odejava.xode.XODEGroup.parseGroup(XODEGroup.java:106)
        at org.odejava.xode.XODESpace.<init>(XODESpace.java:67)
        at org.odejava.xode.XODEWorld.<init>(XODEWorld.java:74)
        at org.odejava.xode.XODERoot.<init>(XODERoot.java:70)
        at org.odejava.xode.XODEParserDOM.parse(XODEParserDOM.java:118)
        at org.odejava.test.xode.XODEExample.<init>(XODEExample.java:101)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
        at java.lang.Class.newInstance0(Class.java:308)
        at java.lang.Class.newInstance(Class.java:261)
        at org.odejava.xith3d.test.RunDemo.main(RunDemo.java:155)
 
Dynamic libraries:
<snip>
 
Heap at VM Abort:
Heap
 def new generation   total 576K, used 63K [0x44720000, 0x447c0000, 0x44c00000)
  eden space 512K,   7% used [0x44720000, 0x44729ce8, 0x447a0000)
  from space 64K,  37% used [0x447a0000, 0x447a6010, 0x447b0000)
  to   space 64K,   0% used [0x447b0000, 0x447b0000, 0x447c0000)
 tenured generation   total 1408K, used 565K [0x44c00000, 0x44d60000, 0x48720000)
   the space 1408K,  40% used [0x44c00000, 0x44c8d6b0, 0x44c8d800, 0x44d60000)
 compacting perm gen  total 4096K, used 3756K [0x48720000, 0x48b20000, 0x4c720000)
   the space 4096K,  91% used [0x48720000, 0x48acb2b8, 0x48acb400, 0x48b20000)
 
Local Time = Sun May  2 11:02:39 2004
Elapsed Time = 22
#
# The exception above was detected in native code outside the VM
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2_04-b05 mixed mode)
#

and…

(edit: snipped)

#4 

Unexpected Signal : 11 occurred at PC=0x4040111A
Function=(null)+0x4040111A
Library=/usr/java/j2sdk1.4.2_04/jre/lib/i386/client/libjvm.so
 
NOTE: We are unable to locate the function name symbol for the error
      just occurred. Please refer to release documentation for possible
      reason and solutions.
 
 
Current Java thread:
        at java.lang.ClassLoader.findLoadedClass(Native Method)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:278)
        - locked <0x44c0f2f8> (a sun.misc.Launcher$ExtClassLoader)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:282)
        - locked <0x44c0f220> (a sun.misc.Launcher$AppClassLoader)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274)
        - locked <0x44c0f220> (a sun.misc.Launcher$AppClassLoader)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
        - locked <0x44c0f220> (a sun.misc.Launcher$AppClassLoader)
        at com.xith3d.render.MaterialShader.<clinit>(MaterialShader.java:54)
        at com.xith3d.render.Renderer.getDefaultPriorities(Renderer.java:222)
        at com.xith3d.render.Renderer.<init>(Renderer.java:64)
        at com.xith3d.scenegraph.View.<init>(View.java:214)
        at org.odejava.xith3d.test.RunDemo.<init>(RunDemo.java:66)
        at org.odejava.xith3d.test.RunDemo.main(RunDemo.java:155)
 Dynamic libraries:
08048000-0804e000 r-xp 00000000 03:06 233919     /usr/java/j2sdk1.4.2_04/jre/bin/java
0804e000-0804f000 rw-p 00005000 03:06 233919     /usr/java/j2sdk1.4.2_04/jre/bin/java

<snip>

Heap at VM Abort:
Heap
 def new generation   total 576K, used 42K [0x44720000, 0x447c0000, 0x44c00000)
  eden space 512K,   1% used [0x44720000, 0x44721d10, 0x447a0000)
  from space 64K,  54% used [0x447b0000, 0x447b8bf8, 0x447c0000)
  to   space 64K,   0% used [0x447a0000, 0x447a0000, 0x447b0000)
 tenured generation   total 1408K, used 1130K [0x44c00000, 0x44d60000, 0x48720000)
   the space 1408K,  80% used [0x44c00000, 0x44d1aa30, 0x44d1ac00, 0x44d60000)
 compacting perm gen  total 4864K, used 4841K [0x48720000, 0x48be0000, 0x4c720000)
   the space 4864K,  99% used [0x48720000, 0x48bda750, 0x48bda800, 0x48be0000)
 
Local Time = Mon May  3 10:22:48 2004
Elapsed Time = 3
#
# HotSpot Virtual Machine Error : 11
# Error ID : 4F530E43505002EF
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2_04-b05 mixed mode)
#

Thanks,

Will.

#5

You bloody legend that was it! Thank you, you have just made my day.

Finally, some deterministic behaviour.

Demo crashes when no -Xms & -Xmx set - Demo works when -Xms and -Xmx are set to 200M

I didn’t think to try that because I wasn’t getting out of memory errors - but it was the minimum heap size - not the maximum which was causing the crash (hence the cryptic dump rather than a kind Java error).

Now when I set the minimum nice and high - the bug doesn’t manifest itself.

Thanks again for helping me find the work around.

Now the question remains - should I submit a bug report to Sun? Surely libc.so and libjvm.so should in theory never crash. I have no qualms in giving them all the code - it’s open source anyway.

;D

Will.

#6

I’ve no idee what actually is going on, but here are some wild speculations:

There is a bug in Ode4java that causes it write to memory that it do not own. It do not cause a access violation because the memory is part of the java heap and owned by the vm. Later the vm needs to move or grow the heap as part of a gc. Somehow some critical memory was trashed by ode wich makes the vm cause a access vialoation when it accesses memory. That is why it works when you set -Xms & -Xmx very high, because the vm don’t need to move/grow the heap.

When I encountered this behavior, it was because I used a opengl get function that wrote outside by nio Buffer. When I fixed the get bug, the native crashes went away.