gdb 在 Alpine Linux 上调试 OpenJDK java 失败，出现“线程收到信号？，未知信号”答案

【问题标题】：gdb debugging OpenJDK java on Alpine Linux fails with "Thread recieved signal ?, Unknown signal"gdb 在 Alpine Linux 上调试 OpenJDK java 失败，出现“线程收到信号？，未知信号”
【发布时间】：2019-02-06 16:56:45
【问题描述】：

我在尝试使用 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 源文件匹配此堆栈跟踪：

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)，然后它就会爆炸。

【问题讨论】：

标签： java gdb signals alpine musl

【解决方案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 CDT 等 GDB 前端。

总结：

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

完整说明：

在 JVM 初始化期间，会创建一个 JavaMain 本机线程，并创建 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 本身。

【讨论】：