gdb在Alpine Linux上调试OpenJDK Java失败，并显示“线程已接收信号？，未知信号”

时间：2018-08-31 16:02:57

标签： java gdb signals alpine musl

我在尝试使用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）。
  • 从带有和不带有/bin/ash的不同shell（/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)

与该堆栈跟踪匹配的音乐源文件：

OpenJDK源代码：

JVMInit尝试通过调用JavaMain创建ContinueInNewThread本机线程，然后调用ContinueInNewThread0(JavaMain, threadStackSize, (void*)&args)并爆炸。

1 个答案:

答案 0 :(得分：3)

TL; DR：问题是gdb ticket中报道的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信号（并且仅当所有线程确认信号{{1}时） }被执行）：

do_setrlimit

但是，r = -__syscall(SYS_tgkill, pid, tid, SIGSYNCCALL); 信号是musl的内部信号，不是由gdb处理的。 gdb显式处理所有信号类型，但是SIGSYNCCALL不包括在已处理信号中（请参阅gdb的signals.c）。因此，当发出信号时，gdb终止，并显示SIGSYNCCALL错误。

解决方法：

解决方法是即时禁用OpenJDK中对Unknown signal的调用。相关代码在setrlimit函数（os_linux.cpp）中：

os::init_2

通过将 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"); } } } 设置为0，不会执行上述代码，并且VM初始化可以正常继续。有一个用于切换此变量MaxFDLimit的命令行选项，但它在Solaris only上可用，因此我们别无选择，只能在gdb中手动关闭此变量。

-XX:-MaxFDLimit背后的原因是历史性的，其目的是增加具有默认FD限制很低的旧系统的文件描述符默认限制（如256），如JDK-8010126中所述。 Alpine V3.8的默认限制为1024，因此禁用此代码应该是安全的-如果需要，可以使用MaxFDLimit而不是JVM本身来增加限制。

相关问题
最新问题