如何使用 jffi / jnr 处理 SIGSEGV？

发布于 2025-01-16 01:29:28 字数 1553 浏览 2 评论 0原文

Java VM 在 Docker 容器中因 SIGSEGV 崩溃。在所有其他系统上，它都按预期工作。

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000000000007966, pid=188, tid=189
#
# JRE version: OpenJDK Runtime Environment Temurin-17.0.2+8 (17.0.2+8) (build 17.0.2+8)
# Java VM: OpenJDK 64-Bit Server VM Temurin-17.0.2+8 (17.0.2+8, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# C  0x0000000000007966

和堆栈跟踪

Current thread (0x00007fbdfa103040):  JavaThread "main" [_thread_in_native, id=189, stack(0x00007fbdff179000,0x00007fbdff279ac8)]

Stack: [0x00007fbdff179000,0x00007fbdff279ac8],  sp=0x00007fbdff277c38,  free space=1019k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  0x0000000000007966

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  com.kenai.jffi.Foreign.invokeN3O1(JJJJJLjava/lang/Object;III)J+0
j  com.kenai.jffi.Invoker.invokeN3(Lcom/kenai/jffi/CallContext;JJJJILjava/lang/Object;Lcom/kenai/jffi/ObjectParameterStrategy;Lcom/kenai/jffi/ObjectParameterInfo;Ljava/lang/Object;Lcom/kenai/jffi/ObjectParameterStrategy;Lcom/kenai/jffi/ObjectParameterInfo;Ljava/lang/Object;Lcom/kenai/jffi/ObjectParameterStrategy;Lcom/kenai/jffi/ObjectParameterInfo;)J+126
j  de.digitalcollections.openjpeg.lib.libopenjp2$jnr$ffi$1.opj_read_header(Ljnr/ffi/Pointer;Ljnr/ffi/Pointer;Ljnr/ffi/byref/PointerByReference;)Z+190

我可以做什么来解决 jffi / jnr 这个问题？我怎样才能收到有关该问题的更多详细信息？

原文

The Java VM crash with a SIGSEGV in a docker container. On all other systems it is working as expected.

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000000000007966, pid=188, tid=189
#
# JRE version: OpenJDK Runtime Environment Temurin-17.0.2+8 (17.0.2+8) (build 17.0.2+8)
# Java VM: OpenJDK 64-Bit Server VM Temurin-17.0.2+8 (17.0.2+8, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# C  0x0000000000007966

and the stack trace

Current thread (0x00007fbdfa103040):  JavaThread "main" [_thread_in_native, id=189, stack(0x00007fbdff179000,0x00007fbdff279ac8)]

Stack: [0x00007fbdff179000,0x00007fbdff279ac8],  sp=0x00007fbdff277c38,  free space=1019k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  0x0000000000007966

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  com.kenai.jffi.Foreign.invokeN3O1(JJJJJLjava/lang/Object;III)J+0
j  com.kenai.jffi.Invoker.invokeN3(Lcom/kenai/jffi/CallContext;JJJJILjava/lang/Object;Lcom/kenai/jffi/ObjectParameterStrategy;Lcom/kenai/jffi/ObjectParameterInfo;Ljava/lang/Object;Lcom/kenai/jffi/ObjectParameterStrategy;Lcom/kenai/jffi/ObjectParameterInfo;Ljava/lang/Object;Lcom/kenai/jffi/ObjectParameterStrategy;Lcom/kenai/jffi/ObjectParameterInfo;)J+126
j  de.digitalcollections.openjpeg.lib.libopenjp2$jnr$ffi$1.opj_read_header(Ljnr/ffi/Pointer;Ljnr/ffi/Pointer;Ljnr/ffi/byref/PointerByReference;)Z+190

What can I do to solve this problem with jffi / jnr? How can I receive more details about the problem?

分享到QQ

分享到微博

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

发布评论

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

旧时浪漫 2025-01-23 01:29:28

Linux 上崩溃的原因是目标操作系统的本机库不兼容。本机库是使用 glibc 编译的，崩溃的操作系统使用 musl 编译的。这不是任何库中的错误。

为了解决这个问题，我们现在捆绑了该库的第二个版本。并与以下代码不同：

ProcessBuilder builder = new ProcessBuilder( "ldd", "/bin/ls" );
Process process = builder.start();
InputStream input = process.getInputStream();
process.waitFor( 5, TimeUnit.SECONDS );
String content = new String( input.readAllBytes() );
LogManager.getConfigLogger().debug( content );
boolean isMuslLibrary = content.contains( "musl-" );

更多详细信息在问题评论中： https://github .com/dbmdz/imageio-jnr/issues/192

开放的问题是为什么 loadLibrary 不抛出错误或者 Java 开发人员如何找到它。

The cause of the crash on Linux was a inkompatible native libraries for the target OS. The native library was compiled with glibc and the OS with the crash use musl. It was not a bug in any of the libraries.

To solve the problem we bundle now a second version of the library. And differ with the follow code:

ProcessBuilder builder = new ProcessBuilder( "ldd", "/bin/ls" );
Process process = builder.start();
InputStream input = process.getInputStream();
process.waitFor( 5, TimeUnit.SECONDS );
String content = new String( input.readAllBytes() );
LogManager.getConfigLogger().debug( content );
boolean isMuslLibrary = content.contains( "musl-" );

More details are in the issue comments: https://github.com/dbmdz/imageio-jnr/issues/192

Open is the question why loadLibrary not throw an error or how an Java developer can find it.

回复收藏 0 原文

~没有更多了~