问题描述

我是在一个 arm 环境的 ubuntu 工控机上跑一个 springboot 些的 java 后端程序，会不时遇到 jvm 崩溃，而且多在调用接口的时候，hs_err_pid*.log 文件显示是在[libpthread.so.0+0x755c]start_thread+0xbc 这个位置, 分析 core dump 文件也是在这个位置崩溃的，

<>可疑的诱因：我这个后端程序会调用一个第三方提供的 so 库文件连接局域网一个相机设备，当相机不在线时我的程序就会变得容易崩溃，但我单独使用同一个 jdk 写一个定时调用该 so 库测试的 demo 时候又没有崩溃的情况发生，不知道是不是我的后端程序有更多复杂业务的原因

使用的 java 版本

java version "17.0.10" 2024-01-16 LTS Java(TM) SE Runtime Environment (build 17.0.10+11-LTS-240) Java HotSpot(TM) 64-Bit Server VM (build 17.0.10+11-LTS-240, mixed mode, sharing)

ubuntu 版本 20.04.5 LTS ，

Linux linux 5.10.110 #2 SMP Mon May 6 16:55:18 CST 2024 aarch64 aarch64 aarch64 GNU/Linux

gdb 分析 core dump 崩溃点的结果：

(gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x0000007fa0695aac in __GI_abort () at abort.c:79 #2 0x0000007f9ffafc38 in os::abort(bool, void*, void const*) () from /userdata/hifi/jdk/lib/server/libjvm.so #3 0x0000007fa01a5f3c in VMError::report_and_die(int, char const*, char const*, std::__va_list, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long) () from /userdata/hifi/jdk/lib/server/libjvm.so #4 0x0000007fa01a6908 in VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*, char const*, ...) () from /userdata/hifi/jdk/lib/server/libjvm.so #5 <signal handler called> #6 0x0000007f9ff9b2f0 in os::is_first_C_frame(frame*) () from /userdata/hifi/jdk/lib/server/libjvm.so #7 0x0000007fa01a0f34 in next_frame(frame, Thread*) () from /userdata/hifi/jdk/lib/server/libjvm.so #8 0x0000007fa01a1fd8 in VMError::print_native_stack(outputStream*, frame, Thread*, char*, int) () from /userdata/hifi/jdk/lib/server/libjvm.so #9 0x0000007fa01a3738 in VMError::report(outputStream*, bool) () from /userdata/hifi/jdk/lib/server/libjvm.so #10 0x0000007fa01a5e30 in VMError::report_and_die(int, char const*, char const*, std::__va_list, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long) () from /userdata/hifi/jdk/lib/server/libjvm.so #11 0x0000007fa01a6908 in VMError::report_and_die(Thread*, unsigned int, unsigned char*, void*, void*, char const*, ...) () from /userdata/hifi/jdk/lib/server/libjvm.so #12 0x0000007fa00623bc in JVM_handle_linux_signal () from /userdata/hifi/jdk/lib/server/libjvm.so #13 <signal handler called> #14 start_thread (arg=<error reading variable: Cannot access memory at address 0x4a28>) at pthread_create.c:478 Backtrace stopped: Cannot access memory at address 0x49c8

jvm

崩溃

8 条回复 2024-05-21 20:08:15 +08:00

cppc

2024-05-20 20:40:01 +08:00

没有找到稳定的复现方法还不好说，大概率是 JAVA 和 C 库共享内存的问题，小概率是 C 库自己的问题。

letianqiu

2024-05-20 23:10:45 +08:00 via Android

看报错的位置是创建新线程的时候，spring boot 的 thread pool 是启动的时候创建的，应该和这个 crash 无关，可以查看一下 so 和业务代码里有没有开新线程

itechify

PRO

2024-05-21 01:49:20 +08:00 via Android

第三方库是 aarch64 编译后的吗？

leegoo

2024-05-21 08:47:26 +08:00

之前我也遇到过 java 调用 c++ 偶发性导致程序崩溃

我的排查过程是，通过增加 jvm 参数
-XX:+CreateMinidumpOnCrash
然后在崩溃的时候会产生 dump 日志，与常规崩溃日志(hs_err_pid*.log )不同的是，他会保留一份类似于 c++ 异常的堆栈以及入参数据

然后开发 c++的工程师就拿着详细的信息，很快就定位到问题了(最终还是代码问题)

leimu012

2024-05-21 09:38:19 +08:00

我之前遇到过 java 调 so 文件就 jvm 崩溃，不过是在容器里才会发生，实体机和虚拟机里不会，我们当时分析是容器缺了部分 c 的环境，但是也不知道怎么排查缺的是什么

dirtydeeds

2024-05-21 09:48:54 +08:00

感谢各位帮忙
@cppc 发现自己对 jna 一点都不熟悉，我查查资料
@oneisall8955 是的, 是 ararch64 编译后的
@letianqiu so 代码对方不提供，也在和对方沟通，不过他们的 demo 跑不出问题就不是很配合
@leegoo 感谢，我试试
@leimu012 谢谢回复，原本这个项目是也是要放 x64 环境 docker 跑的，不过领导搞了个工控机让部署

letianqiu

2024-05-21 11:41:34 +08:00

@dirtydeeds 你可以尝试一下让 spring boot 里调用该库的 method 不要被 JIT 。类似`-X:CompileCommand=exclude,the/package/and/Class,methodName`。然后看看是不是还是 crash 在同样的地方

cppc

2024-05-21 20:08:15 +08:00

分享一点经验：

## C 风格字符串

需要注意 C 风格字符串是靠 null-byte(0x0)标记字符串长度

## 结构体传参

要注意是 ByReference 还是 ByValue ，核对 C 端的函数原型

## 结构体内存布局

要注意对齐方式,仔细核对 C 端的结构体声明

## 结构体 memory dump

开启 `-Djna.dump_memory=true`

> Normally when you invoke toString on a Structure, it will print each defined field with its calculated memory offset. If when launching the VM, you pass it "-Djna.dump_memory=true", toString will also dump the contents of the corresponding native memory. This is useful to determine if you've added or omitted a field, or chosen an incorrect size. Viewing the memory as bytes usually makes it clear where field boundaries should be, assuming the memory has been initialized by native code.

## 日志

对 C 端的函数调用做一下封装,调用前后记录日志，先把崩溃的位置找到

[求助]关于一个 jvm 崩溃的问题

问题描述