java - gdb 在 Alpine Linux 上调试 OpenJDK java 失败，出现 "Thread recieved signal ?, Unknown signal"

Question

我在尝试使用 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)。
• 从不同的 shell(/bin/ash、/bin/bash)运行，使用和不使用 sudo。
• 在 .gdbinit 中禁用信号停止:handle SIGSEGV nostop noprint pass，同样适用于 SIGPIPE、SIGHUP，SIGFPE，SIG34。
• 将 set startup-with-shell off 添加到 .gdbinit。

感谢您的帮助!

编辑:

这是抛出未知信号的完整堆栈，它导致 JVMInit 失败:

(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) 

匹配此堆栈跟踪的 musl 源文件:

• 1: http://git.musl-libc.org/cgit/musl/tree/src/thread/pthread_cancel.c
• 2:http://git.musl-libc.org/cgit/musl/tree/src/thread/__timedwait.c
• 3、4:http://git.musl-libc.org/cgit/musl/tree/src/thread/pthread_join.c

OpenJDK 源代码:

• 7: https://github.com/frohoff/jdk8u-jdk/blob/master/src/solaris/bin/java_md_solinux.c

JVMInit 尝试通过调用 ContinueInNewThread 创建 JavaMain native 线程，后者调用 ContinueInNewThread0(JavaMain, threadStackSize, (void *)&args)，然后它就爆炸了。

Answer 1

TL;DR:问题是 GDB 缺乏对内部 musl 信号的支持，在此 gdb ticket 中报告.

此处提供了快速修补的 GDB:
https://github.com/shaharv/alpine-gdb-builds/releases/tag/v0.1

补丁提交: shaharv/binutils-gdb@0ca9c66 .

通过补丁，信号正确识别为 SIGSYNCCALL。
然后，可以使用 handle SIGSYNCCALL nostop noprint pass 屏蔽它。

---

幸运的是，我能够想出一个解决方法!
调试 Alpine OpenJDK java 时的 gdb 崩溃可以通过以下方式解决:

• 启动gdb
• 中断 os::init_2
• 使用所需的命令行参数运行 java
• 当遇到断点时，设置 MaxFDLimit=0
• 继续，正常调试。

我已经使用 OpenJDK 8 和 11 早期访问测试了变通方法，因此它也可能适用于 OpenJDK 9 和 10。

不幸的是，此解决方法的范围非常有限:

• 它仅在 JDK 具有调试符号时有效 - 无论是本地调试 OpenJDK 构建还是使用 openjdk8-dbg 调试符号包。
• 它仅适用于命令行 gdb，不适用于 CLion 和 Eclipse CDT 等 GDB 前端。

总结:

当在 gdb 中调用 setrlimit 函数时发生崩溃。 musl 的 setrlimit 实现使用 SIGSYNCCALL 向线程发出信号，gdb 不支持它，并导致 Unknown signal 错误。为避免该错误，通过关闭MaxFDLimit 全局变量来禁用JavaMain 的相关初始化代码。

完整解释:

在 JVM 初始化期间，创建了一个 JavaMain native 线程，并创建了 VM。在 VM 创建过程中，存在特定于操作系统的初始化，其中调用了 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 函数调用。musl 的 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 信号(并且仅当所有线程都确认该信号时， do_setrlimit 被执行):

r = -__syscall(SYS_tgkill, pid, tid, SIGSYNCCALL);

但是，SIGSYNCCALL 信号是 musl 的内部信号，不由 gdb 处理。 gdb 显式处理所有信号类型，但 SIGSYNCCALL 不包含在处理的信号中(参见 gdb 的 signals.c )。因此，当发出信号时，gdb 将终止并出现Unknown signal 错误。

解决方法:

解决方法是在 OpenJDK 中即时禁用对 setrlimit 的调用。相关代码在os::init_2函数中(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");
      }
    }
  }

通过将MaxFDLimit设置为0，上面的代码不会执行，VM初始化可以正常进行。有一个用于切换此变量的命令行选项 -XX:-MaxFDLimit，但它在 Solaris only 上可用。 ，所以我们别无选择，只能在 gdb 中手动关闭此变量。

MaxFDLimit 背后的原因是历史性的，旨在增加默认 FD 限制 (256) 非常低的古代系统的文件描述符默认限制，如 JDK-8010126 中所述。 . Alpine V3.8 的默认限制为 1024，因此禁用此代码应该是安全的 - 如果需要，可以使用 ulimit 增加限制，而不是通过 JVM 本身。