JNA 导致 EXCEPTION_ACCESS_VIOLATION?

发布于 2024-07-11 17:37:02 字数 2085 浏览 10 评论 0原文

我的 Java UI 意外终止并转储 hs_err_pid 文件。 该文件显示“崩溃发生在 Java 虚拟机之外的本机代码中”。 JNA 是我们使用的唯一本机代码。 有谁知道任何 JNA 版本可能导致此问题的任何已知问题或错误。 我已经包含了下面错误文件中的一些内容。

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

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

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

独留℉清风醉 2024-07-18 17:37:02

我刚刚遇到了同样的错误,这显然是 1.6.0_11 中新的 Direct3d 加速 Java2d 功能中的一个错误,该错误发生在视频 RAM 较低的机器上。
如果您使用 -Dsun.java2d.d3d=false 启动应用程序,它应该会再次工作。
Sun bug 跟踪如下: https://bugs.java.com/bugdatabase /view_bug?bug_id=6788497

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: https://bugs.java.com/bugdatabase/view_bug?bug_id=6788497

情徒 2024-07-18 17:37:02

从以下情况来看:(

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]

此时堆栈跟踪显然爆炸了)您可能遇到了 AWT 库中的错误。

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.

烈酒灼喉 2024-07-18 17:37:02

仅仅因为您有意使用的唯一本机代码是 JNI/其他内容,并不意味着像您这样的崩溃在位置或时间上与它相关。 在任何给定的 JVM/执行中都会默默地使用各种本机支持,并且我曾经遇到过奇怪的崩溃,这些崩溃最终是由更早发生的损坏和 JVM 本身引起的。

就我而言,我在闪亮的新多 CPU (Niagara) 机器上的并发 GC 线程中发现了令人兴奋的错误,这使得各种炸弹等待爆炸,而我没有非-我的应用程序中完全有 JDK 本机代码。

当 Sun 的 GC 团队修复了他们的错误(并且非常友善地为我提供了一个测试盗版 VM)时,我的问题就消失了(当然,在一两轮之后)。

达蒙

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

往事随风而去 2024-07-18 17:37:02

您遇到了访问冲突,这意味着某些代码试图访问不允许的地址,通常是因为给定地址处没有任何内存。 堆栈跟踪指向出现问题的位置,这可能是问题的根源,也可能不是问题的根源。 人们在谈论本机代码时有时会忘记这一点,即使他们在其他方面意识到这一点。

我使用过 JNA,但从来没有遇到过任何问题。 如果出现访问冲突,那是我的错。 这里有一些简单的建议。

确保您的机器物理性能良好。 使用 Memtest86+ 测试您的记忆力。 如果是硬件问题,那么寻找软件错误是没有用的。

查看使用JNA 的代码。 请注意,即使 Java 中的调用看起来不起眼,您所编写的低级代码也可能会搞乱任何事情。 使用 JNA 的代码很可能会做错事并损坏内存。 例如,确保使用正确的调用约定和数据对齐。 如果有疑问,请找熟悉 C(或者更一般的、低级的东西)的人来帮助您。

不要完全排除其他因素。 您很可能遇到了 JVM 错误或其他问题,但要小心这种情况的可能性。 如果您听到马蹄声,请想到马,而不是斑马。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文