2

My Java UI unexpectly terminated and dumped an hs_err_pid file. The file says "The crash happened outside the Java Virtual Machine in native code." JNA is the only native code we use. Does anyone know of any know issues or bugs with any JNA version that might cause this. I've included some of the contents from the error file below. 

An unexpected error has been detected by Java Runtime Environment:

EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6d02bcbd, pid=312, tid=3616

 Java VM: Java HotSpot(TM) Client VM (11.0-b16 mixed mode, sharing windows-x86)<br>
 Problematic frame:
 C  [awt.dll+0x2bcbd]

 If you would like to submit a bug report, please visit:
   http://java.sun.com/webapps/bugreport/crash.jsp
 The crash happened outside the Java Virtual Machine in native code.
 See problematic frame for where to report the bug.

Current thread (0x02acf000):  JavaThread "AWT-Windows" daemon [_thread_in_native, id=3616, stack(0x02eb0000,0x02f00000)]

siginfo: ExceptionCode=0xc0000005, writing address 0xe2789280


Registers:
EAX=0x234f099c, EBX=0x00001400, ECX=0x00000100, EDX=0xe2789280
ESP=0x02eff4a4, EBP=0x00000400, ESI=0x234f099c, EDI=0xe2789280
EIP=0x6d02bcbd, EFLAGS=0x00010206

Top of Stack: (sp=0x02eff4a4)
0x02eff4a4:   02eff500 00000100 02eff584 00000100
0x02eff4b4:   6d0a5697 00000400 00000400 00000100
0x02eff4c4:   00000100 02eff700 02eff500 00000000
0x02eff4d4:   00000000 00000100 041ac3a0 00000100
0x02eff4e4:   00182620 00000400 e2789280 00000000
0x02eff4f4:   00000000 00000100 00000100 00000000
0x02eff504:   00000000 00000100 00000100 00000000
0x02eff514:   00000000 00000004 00000400 00000000

Instructions: (pc=0x6d02bcbd)
0x6d02bcad:   00 00 00 8b 4c 24 14 8b e9 c1 e9 02 8b f0 8b fa
0x6d02bcbd:   f3 a5 8b cd 83 e1 03 f3 a4 8b 74 24 18 8b 4c 24

Stack: [0x02eb0000,0x02f00000],  sp=0x02eff4a4,  free space=317k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [awt.dll+0x2bcbd]

[error occurred during error reporting (printing native stack), id 0xc0000005]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  sun.awt.windows.WToolkit.eventLoop()V+0
j  sun.awt.windows.WToolkit.run()V+69
j  java.lang.Thread.run()V+11
v  ~StubRoutines::call_stub
Raedwald
  • 46,613
  • 43
  • 151
  • 237
richs
  • 4,699
  • 10
  • 43
  • 56

4 Answers4

3

I just hit that very same bug, it's apppearantly a bug in the new Direct3d accelerated Java2d functionality with 1.6.0_11 that happens with machines with low video ram. If you start your app with -Dsun.java2d.d3d=false it should work again. The sun bug tracking this is the following: http://bugs.sun.com/view_bug.do?bug_id=6788497

1

Judging from:

Stack: [0x02eb0000,0x02f00000], sp=0x02eff4a4, free space=317k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [awt.dll+0x2bcbd]

(at which point the stack trace apparently blew up) you might be hitting a bug in the AWT library.

Lawrence Dol
  • 63,018
  • 25
  • 139
  • 189
1

Just because the only bit of native code you knowingly use is JNI/whatever doesn't mean a crash like yours is related to it in location or in time. There's all sorts of native support used silently in any given JVM/execution, and I was at one time getting bizarre crashes caused in the end by corruption that had happened much earlier and by the JVM itself.

In my case I was finding exciting bugs in the threading of concurrent GC on my shiny new multi-CPU (Niagara) box, that was leaving all sorts of bombs waiting to go off, and I had no non-JDK native code in my app at all.

When Sun's GC team fixed their bug (and very kindly supplied me with a test bootleg VM) my issues evaporated (well, after a round or two, natch).

Rgds

Damon

0

You've hit an access violation, meaning that some code tried to access an address it's not allowed to, often because there isn't any memory at the given address. The stacktrace points to the location that tripped over the problem, which may or may not be the source of the problem. People sometimes forget about this when talking about native code, even if they are aware of it otherwise.

I've used JNA, but never had any issue with it. If there was an access violation it was my fault. Here's some simple advice.

Make sure your machine is physically sound. Test your memory with Memtest86+. There's no use hunting a software bug if it's a hardware problem.

Look at the code using JNA. Be aware that even if the calls in Java look inconspicuous, you're writing low level code that can mess with anything. Quite possible, the code using the JNA does something wrong and corrupts the memory. For example, make sure the correct calling convention and data alignment is used. If in doubt, get someone who's comfortable with C (or, more general, low level stuff) to help you.

Don't completely rule out other factors. It may well be that you hit a JVM bug or something, but be careful how likely this is. If you hear hoofbeats, think horses, not zebras.

Ronald Blaschke
  • 4,036
  • 2
  • 22
  • 16