2

我在尝试使用 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 错误、未捕获的异常、堆栈溢出和其他应用程序错误。

在 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 源代码：

JVMInit尝试通过调用, 调用来创建本JavaMain机线程，然后它就会爆炸。ContinueInNewThreadContinueInNewThread0(JavaMain, threadStackSize, (void*)&args)

4

1 回答 1

3

TL;DR：问题是 GDB 缺乏对内部 musl 信号的支持，在这个gdb 票中报告。

此处提供了一个快速而肮脏的修补 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实现使用 gdb 不支持的 向线程发出信号SIGSYNCCALL，并导致Unknown signal错误。JavaMain为了避免错误，通过关闭MaxFDLimit全局变量来禁用相关的初始化代码。

完整解释：

在 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错误而终止。

解决方法：

setrlimit解决方法是在运行中禁用OpenJDK 中的调用。相关代码在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上可用，因此我们别无选择，只能在 gdb 中手动关闭此变量。

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

于 2018-09-03T07:00:40.543 回答