为什么一个Rsession进程可以在SIGSEGV之后继续，它是什么意思

Question

我正在为自己开发一个 R 包，它与使用 rJava 的 Java 代码和使用 Rcpp 的 C++ 代码交互。在使用 lldb 在 Rstudio 下工作时尝试调试 Rsession 崩溃时，我注意到当我尝试加载我正在开发的包时 lddb 输出以下消息：

(lldb) Process 19030 stopped
* thread #1, name = 'rsession', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
    frame #0: 0x00007fe6c7b872b4
->  0x7fe6c7b872b4: movl   (%rsi), %eax
    0x7fe6c7b872b6: leaq   0xf8(%rbp), %rsi
    0x7fe6c7b872bd: vmovdqu %ymm0, (%rsi)
    0x7fe6c7b872c1: vmovdqu %ymm7, 0x20(%rsi)

（其中 19030 是 rsession 的 pid）。此时，Rstudio 停止等待 lldb 恢复执行，但没有得到可怕的 "R session aborted" 弹出窗口，而是在 lldb 中输入 'c' 命令恢复 rsession 进程，Rstudio 继续正常运行，我可以使用加载的包没有问题。即：

c
Process 19030 resuming

这是怎么回事？如果 lldb 说它有 "stopped"，为什么 Rstudio 的 rsession 不会崩溃？这是由于 R 的（或 Rstudio 的？）SIGSEGV 处理机制造成的吗？这是否意味着原始的 SIGSEGV 是虚假的，不应该引起关注？当然（但在这个问题中可能偏离主题）：我如何理解 lldb 的输出以确定是否应该进一步调试加载我的包时的这个 SIGSEGV？

Answer 1

SIGSEGV 不是发生在Rsession 的进程中，而是发生在rJava 加载包时启动的JVM 进程中。这种行为是已知的，并且由于 JVM 的内存管理，如 here:

所述

Java uses speculative loads. If a pointer points to addressable memory, the load succeeds. Rarely the pointer does not point to addressable memory, and the attempted load generates SIGSEGV ... which java runtime intercepts, makes the memory addressable again, and restarts the load instruction.

建议的 gdb 解决方法工作正常：

(gdb) handle SIGSEGV nostop noprint pass

为什么一个Rsession进程可以在SIGSEGV之后继续，它是什么意思

Why can an Rsession process continue after SIGSEGV and what does it mean

debugging

r

lldb