gdb调试Alpine Linux上的OpenJDK java失败了“线程接收信号?,未知信号”

问题描述 投票:2回答:1

我在使用gdb尝试在Alpine Linux上调试OpenJDK java时遇到了困难 - 是否有人成功地这样做了?

当试图在gdb中调试java时,例如,gdb javar -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 buguncaught exceptionstack overflow和其他应用程序错误。

在gdb之外,java正在运行没有任何问题,并且gdb在调试简单的C ++程序时工作正常。我正在运行Alpine V3.8。

我试过的事情:

  • 不同的gdb版本(8.0.1-r68.0.1-r37.12.1-r1)。
  • 不同的OpenJDK版本(1.8.0_1711.7.0_181)。
  • 从不同的贝壳(qazxsw poi,qazxsw poi)运行,有和没有qazxsw poi。
  • 禁止在/bin/ash/bin/bash停止信号,同样为sudo.gdbinithandle SIGSEGV nostop noprint passSIGPIPE停止。
  • 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 '\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,并在那里爆炸。

java gdb signals alpine musl
1个回答
3
投票

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。

不幸的是,这种解决方法的范围非常有限:

  • 它仅在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>) ,意思是,从异步信号处理程序调用它是安全的。正在通过调用setrlimitsetrlimit)来处理同步部分:

AS-Safe

__synccallsetrlimit.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本身来增加限制。

© www.soinside.com 2019 - 2024. All rights reserved.