gdb调试Alpine Linux上的OpenJDK java失败了“线程接收信号?,未知信号”
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了gdb调试Alpine Linux上的OpenJDK java失败了“线程接收信号?,未知信号”相关的知识,希望对你有一定的参考价值。
我在使用gdb尝试在Alpine Linux上调试OpenJDK java时遇到了困难 - 是否有人成功地这样做了?
当试图在gdb中调试java时,例如,gdb java
和r -version
,它会立即失败:
Thread 1 "java" recieved signal ?, Unknown signal.
__cp_end () at src/thread/x86_64/syscall_cp.s:29
我搜索并搜索但找不到任何关于Alpine的OpenJDK调试的参考或解决方案。
在其他平台(macOS Sierra,MinGW)上看到的处理相同gdb错误的其他线程表明,recieved signal ?, Unknown signal
可能由各种原因导致,包括gdb bug,uncaught exception,stack overflow和其他应用程序错误。
在gdb之外,java正在运行没有任何问题,并且gdb在调试简单的C ++程序时工作正常。我正在运行Alpine V3.8。
我试过的事情:
- 不同的gdb版本(
8.0.1-r6
,8.0.1-r3
,7.12.1-r1
)。 - 不同的OpenJDK版本(
1.8.0_171
,1.7.0_181
)。 - 从不同的贝壳(qazxsw poi,qazxsw poi)运行,有和没有qazxsw poi。
- 禁止在
/bin/ash
:/bin/bash
停止信号,同样为sudo
,.gdbinit
,handle SIGSEGV nostop noprint pass
,SIGPIPE
停止。 - 将
SIGHUP
添加到SIGFPE
。
谢谢你的帮助!
编辑:
这是抛出未知信号的完整堆栈,这会导致JVMInit失败:
SIG34
与此堆栈跟踪匹配的musl源文件:
- 1:
set startup-with-shell off
- 2:
.gdbinit
- 3,4:
(gdb) r -version Starting program: /usr/lib/jvm/java-1.8-openjdk/bin/java -version process 16214 is executing new program: /usr/lib/jvm/java-1.8-openjdk/bin/java [New LWP 16219] Thread 1 "java" received signal ?, Unknown signal. __cp_end () at src/thread/x86_64/syscall_cp.s:29 29 src/thread/x86_64/syscall_cp.s: No such file or directory. (gdb) info threads Id Target Id Frame * 1 LWP 16214 "java" __cp_end () at src/thread/x86_64/syscall_cp.s:29 2 LWP 16219 "java" __synccall (func=func@entry=0x7ffff7da2662 <do_setrlimit>, ctx=ctx@entry=0x7ffff7ff4720) at src/thread/synccall.c:143 (gdb) where #0 __cp_end () at src/thread/x86_64/syscall_cp.s:29 #1 0x00007ffff7dbed2d in __syscall_cp_c (nr=202, u=<optimized out>, v=<optimized out>, w=<optimized out>, x=<optimized out>, y=<optimized out>, z=0) at src/thread/pthread_cancel.c:35 #2 0x00007ffff7dbe350 in __timedwait_cp (addr=addr@entry=0x7ffff7ff4b20, val=16219, clk=clk@entry=0, at=at@entry=0x0, priv=priv@entry=0) at src/thread/__timedwait.c:31 #3 0x00007ffff7dbfdc4 in __pthread_timedjoin_np (t=0x7ffff7ff4ae8, res=res@entry=0x7fffffffa348, at=at@entry=0x0) at src/thread/pthread_join.c:16 #4 0x00007ffff7dbfe02 in __pthread_join (t=<optimized out>, res=res@entry=0x7fffffffa348) at src/thread/pthread_join.c:27 #5 0x00007ffff7b6695e in ContinueInNewThread0 (continuation=continuation@entry=0x7ffff7b61a60 <JavaMain>, stack_size=1048576, args=args@entry=0x7fffffffa3e0) at /home/buildozer/aports/community/openjdk8/src/icedtea-3.8.0/openjdk/jdk/src/solaris/bin/java_md_solinux.c:1046 #6 0x00007ffff7b634a4 in ContinueInNewThread (ifn=ifn@entry=0x7fffffffa4f0, threadStackSize=<optimized out>, argc=1, argv=<optimized out>, mode=mode@entry=841574793, what=what@entry=0x0, ret=0) at /home/buildozer/aports/community/openjdk8/src/icedtea-3.8.0/openjdk/jdk/src/share/bin/java.c:2024 #7 0x00007ffff7b66a08 in JVMInit (ifn=ifn@entry=0x7fffffffa4f0, threadStackSize=<optimized out>, argc=<optimized out>, argv=<optimized out>, mode=841574793, mode@entry=0, what=what@entry=0x0, ret=<optimized out>) at /home/buildozer/aports/community/openjdk8/src/icedtea-3.8.0/openjdk/jdk/src/solaris/bin/java_md_solinux.c:1093 #8 0x00007ffff7b63e30 in JLI_Launch (argc=<optimized out>, argv=<optimized out>, jargc=<optimized out>, jargv=<optimized out>, appclassc=1, appclassv=0x0, fullversion=0x555555554843 "1.8.0_171-b11", dotversion=0x55555555483f "1.8", pname=0x55555555483a "java", lname=0x555555554832 "openjdk", javaargs=0 ' 00', cpwildcard=1 ' 01', javaw=0 ' 00', ergo=0) at /home/buildozer/aports/community/openjdk8/src/icedtea-3.8.0/openjdk/jdk/src/share/bin/java.c:304 #9 0x0000555555554691 in main (argc=<optimized out>, argv=<optimized out>) at /home/buildozer/aports/community/openjdk8/src/icedtea-3.8.0/openjdk/jdk/src/share/bin/main.c:125 (gdb)
OpenJDK源代码:
http://git.musl-libc.org/cgit/musl/tree/src/thread/__timedwait.c试图创建http://git.musl-libc.org/cgit/musl/tree/src/thread/pthread_join.c原生线程,通过调用https://github.com/frohoff/jdk8u-jdk/blob/master/src/solaris/bin/java_md_solinux.c,它调用JVMInit
,并在那里爆炸。
TL; DR:问题是GDB缺乏对内部musl信号的支持,据JavaMain
报道。
这里提供了一个快速修补的GDB:
ContinueInNewThread
补丁提交:ContinueInNewThread0(JavaMain, threadStackSize, (void*)&args)
。
使用补丁,信号正确识别为SIGSYNCCALL。 然后,它可以使用gdb ticket掩盖。
谢天谢地,我能够想出一个解决方法! 调试Alpine OpenJDK java时gdb崩溃可以通过以下方式转移:
- 启动gdb
- https://github.com/shaharv/alpine-gdb-builds/releases/tag/v0.1
- 使用所需的命令行参数运行java
- 当断点被击中时,shaharv/binutils-gdb@0ca9c66
- 继续,并正常调试。
我已经使用OpenJDK 8和11早期访问测试了该变通方法,因此它也可能适用于OpenJDK 9和10。
不幸的是,这种解决方法的范围非常有限:
- 它仅在JDK具有调试符号时有效 - 无论是本地调试OpenJDK构建还是使用
handle SIGSYNCCALL nostop noprint pass
调试符号包。 - 它仅适用于命令行gdb,不适用于像CLion和Eclipse CDT这样的GDB前端。
摘要:
当在gdb内部调用break os::init_2
函数时发生崩溃。 musl的set MaxFDLimit=0
实现用openjdk8-dbg
信号线程,gdb不支持,并且导致setrlimit
错误。为了避免错误,通过关闭setrlimit
全局变量来禁用SIGSYNCCALL
的相关初始化代码。
完整说明:
在JVM初始化期间,将创建Unknown signal
本机线程,并创建VM。在VM创建期间,存在操作系统特定的初始化,其中调用JavaMain
。这是堆栈跟踪的相关部分:
MaxFDLimit
culprint是JavaMain
函数调用。 musl的setrlimit
实现是#0 __synccall (func=func@entry=0x7ffff7da2662 <do_setrlimit>, ctx=ctx@entry=0x7ffff7ff4720) at src/thread/synccall.c:48
#1 0x00007ffff7da26a1 in setrlimit (resource=resource@entry=7, rlim=rlim@entry=0x7ffff7ff4750) at src/misc/setrlimit.c:42
#2 0x00007ffff73bd1fe in os::init_2 ()
at /home/buildozer/aports/community/openjdk8/src/icedtea-3.8.0/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:5096
#3 0x00007ffff746177d in Threads::create_vm (args=0x7ffff7ff4a20, canTryAgain=canTryAgain@entry=0x7ffff7ff4987)
at /home/buildozer/aports/community/openjdk8/src/icedtea-3.8.0/openjdk/hotspot/src/share/vm/runtime/thread.cpp:3361
#4 0x00007ffff729cd48 in JNI_CreateJavaVM (vm=0x7ffff7ff4a10, penv=0x7ffff7ff4a18, args=<optimized out>)
at /home/buildozer/aports/community/openjdk8/src/icedtea-3.8.0/openjdk/hotspot/src/share/vm/prims/jni.cpp:5221
#5 0x00007ffff7b61b0b in InitializeJVM (ifn=<synthetic pointer>, penv=0x7ffff7ff4a18, pvm=0x7ffff7ff4a10)
at /home/buildozer/aports/community/openjdk8/src/icedtea-3.8.0/openjdk/jdk/src/share/bin/java.c:1231
#6 JavaMain (_args=<optimized out>)
,意思是,从异步信号处理程序调用它是安全的。正在通过调用setrlimit
(setrlimit
)来处理同步部分:
AS-Safe
__synccall
(setrlimit.c)阻塞所有信号,然后迭代进程的所有线程并向它们发送int setrlimit(int resource, const struct rlimit *rlim)
{
struct ctx c = { .res = resource, .rlim = rlim, .err = -1 };
__synccall(do_setrlimit, &c);
if (c.err) {
if (c.err>0) errno = c.err;
return -1;
}
return 0;
}
信号(并且只有当所有线程都确认信号时,才执行__synccall
):
synccall.c
但是,SIGSYNCCALL
信号是musl的内部信号,不受gdb处理。 gdb显式处理所有信号类型,但do_setrlimit
不包含在处理信号中(参见gdb的r = -__syscall(SYS_tgkill, pid, tid, SIGSYNCCALL);
)。因此,当信号被提升时,gdb以SIGSYNCCALL
错误终止。
解决方法:
解决方法是在OpenJDK中即时禁用对SIGSYNCCALL
的调用。相关代码在signals.c函数(Unknown signal
)中:
setrlimit
通过将os::init_2
设置为0,不执行上面的代码,并且VM初始化可以正常继续。有一个命令行选项可以切换这个变量os_linux.cpp,但它可以在 if (MaxFDLimit) {
// set the number of file descriptors to max. print out error
// if getrlimit/setrlimit fails but continue regardless.
struct rlimit nbr_files;
int status = getrlimit(RLIMIT_NOFILE, &nbr_files);
if (status != 0) {
if (PrintMiscellaneous && (Verbose || WizardMode))
perror("os::init_2 getrlimit failed");
} else {
nbr_files.rlim_cur = nbr_files.rlim_max;
status = setrlimit(RLIMIT_NOFILE, &nbr_files);
if (status != 0) {
if (PrintMiscellaneous && (Verbose || WizardMode))
perror("os::init_2 setrlimit failed");
}
}
}
上找到,所以我们别无选择,只能在gdb中手动关闭这个变量。
MaxFDLimit
背后的原因是历史性的,并且用于增加具有非常低的默认FD限制(256)的古代系统的文件描述符默认限制,如-XX:-MaxFDLimit
中所述。 Alpine V3.8的默认限制为1024,因此禁用此代码应该是安全的 - 如果需要,可以使用Solaris only而不是JVM本身来增加限制。
以上是关于gdb调试Alpine Linux上的OpenJDK java失败了“线程接收信号?,未知信号”的主要内容,如果未能解决你的问题,请参考以下文章
无法从 Visual Studio 启动 gdb 以在 Windows 上的 Linux 子系统中远程调试 Linux C++ 项目