Consistency
Consistency

Reputation: 2922

R Session Aborted when attaching lldb debuger

I try to use lldb to debug seg fault error in the R package I am developing. I've seen some other questions on SO which use lldb to debug R packages successfully. But I can't get it to work....

I first start a new Rstudio process and want to attach lldb to the rsession process by the following command:

(lldb) process attach -name rsession

And then Rstudio will say that "R Session Aborted" and I have the following message in lldb:

Process 20658 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    frame #0: 0x00007fffb69b2bf2 libsystem_kernel.dylib`__psynch_cvwait + 10
libsystem_kernel.dylib`__psynch_cvwait:
->  0x7fffb69b2bf2 <+10>: jae    0x7fffb69b2bfc            ; <+20>
    0x7fffb69b2bf4 <+12>: movq   %rax, %rdi
    0x7fffb69b2bf7 <+15>: jmp    0x7fffb69abcaf            ; cerror_nocancel
    0x7fffb69b2bfc <+20>: retq  

And even I type the c command into lldb, lldb gives me message that the process is resuming, but Rstudio is still stucked with "R Session Aborted".

(lldb) c
Process 20658 resuming
(lldb) 

If I click Rstudio's start new session, I will have a new rsession process, which is not attached by lldb....

What should I do to debug rsession using lldb?

I'm currently using mac Sierra 10.12.5

Upvotes: 1

Views: 289

Answers (1)

Oo.oO
Oo.oO

Reputation: 13375

This approach worked for me

In first terminal window

> lldb /Applications/RStudio.app/Contents/MacOS/RStudio
(lldb) b fork
(lldb) run
# breakpoint hit - start second lldb
# after running second lldb
(lldb) cont                # first fork
(lldb) cont                # second call to fork

In second terminal window

lldb
(lldb) pro at -n rsession -w
Process 1428 stopped
....
Executable module set to "/Applications/RStudio.app/Contents/MacOS/rsession".
Architecture set to: x86_64-apple-macosx.
(lldb) cont
Process 1428 resuming
(lldb)

I am inside lldb and I don't get nasty message regarding failing session.

Update:

It was reported by @Consistency that using slightly different command in lldb might be required:

(lldb) pro at -n rsession

Upvotes: 1

Related Questions