SIGSEGVの後にRsessionプロセスを続けることができます。何を意味するのですか？

Question

RJPを使用するJavaコードとRcppを使用するC++コードの両方と相互作用するRパッケージを開発しています。 lldbを使用してRstudioの下で作業するとき、デバッグRsessionクラッシュしようとしている間、私は私が開発していたパッケージをロードしようとすると、lddbは、次のメッセージを出力していることに気づいた：（19030はrsessionのPIDである）

(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) 

。この時点で、Rstudioはlldbが実行を再開するのを待たずに、恐ろしい "R session aborted"ポップアップを表示する代わりに、lldbに 'c'コマンドを入力するとrsessionプロセスを再開し、Rstudioはうまくいっていきます。パッケージに問題はありません。すなわち：

c 
Process 19030 resuming 

ここでは何が起こっていますか？ lldbが "停止"しているとRstudioのrsessionがクラッシュしないのはなぜですか？これは、Rの（またはRstudioの）SIGSEGVの処理機構のためですか？元のSIGSEGVが偽であり、心配するべきではないということですか？もちろん、（おそらくこの質問では話題にはなりません）：私のパッケージをロードする際のこのSIGSEGVがさらにデバッグされるべきかどうかを確かめるために、lldbの出力をどのように理解できますか？

Answer 1

SIGSEGVはRsessionのプロセスでは発生しませんが、パッケージロード時にrJavaによって起動されたJVMプロセスで発生します。この動作は既知であり、JVMのメモリ管理のために、here：

Javaは投機的負荷を使用します。ポインタがアドレス指定可能な メモリを指す場合、ロードは成功します。ごくまれにポインタが アドレス可能なメモリを指しておらず、試行されたロードによってSIGSEGV ...が生成されます。 Javaランタイムはインターセプトし、メモリを再度アドレス可能にし、 はロード命令を再開します。

gdbのために提案された回避策が正常に動作します：

(gdb) handle SIGSEGV nostop noprint pass