我在使用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。
我试过的事情:
8.0.1-r6
,8.0.1-r3
,7.12.1-r1
)。1.8.0_171
,1.7.0_181
)。/bin/ash
:/bin/bash
停止信号,同样为sudo
,.gdbinit
,handle SIGSEGV nostop noprint pass
,SIGPIPE
停止。SIGHUP
添加到SIGFPE
。谢谢你的帮助!
编辑:
这是抛出未知信号的完整堆栈,这会导致JVMInit失败:
SIG34
与此堆栈跟踪匹配的musl源文件:
set startup-with-shell off
.gdbinit
(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 '\000', cpwildcard=1 '\001', javaw=0 '\000', 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崩溃可以通过以下方式转移:
我已经使用OpenJDK 8和11早期访问测试了该变通方法,因此它也可能适用于OpenJDK 9和10。
不幸的是,这种解决方法的范围非常有限:
handle SIGSYNCCALL nostop noprint pass
调试符号包。摘要:
当在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本身来增加限制。