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, 和其他应用程序错误.

在 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 '[=14=]0', cpwildcard=1 '[=14=]1', javaw=0 '[=14=]0', 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 源文件：

OpenJDK 源代码：

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

JVMInit 尝试通过调用 ContinueInNewThread 创建 JavaMain 本机线程，后者调用 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
break os::init_2
运行 java 使用所需的命令行参数
当命中断点时，set MaxFDLimit=0
继续，正常调试。

我已经使用 OpenJDK 8 和 11 抢先体验测试了解决方法，因此它也可能适用于 OpenJDK 9 和 10。

遗憾的是，此解决方法的范围非常有限：

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

总结：

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

完整说明：

在 JVM 初始化期间，会创建一个 JavaMain 本机线程，并创建 VM。在 VM 创建期间，有 OS 特定的初始化，其中调用了 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, meaning, it's safe to call it from asynchronous signal handlers. The synchronization part is being handled by calling __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 本身来增加限制。

gdb 在 Alpine Linux 上调试 OpenJDK java 失败并显示 "Thread recieved signal ?, Unknown signal"

gdb debugging OpenJDK java on Alpine Linux fails with "Thread recieved signal ?, Unknown signal"

java

gdb

signals

musl

alpine