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