Julia REPL segfaults when loading R's sf package through RCall.jl

[ianfiske]

I wasn't sure whether to open this in RCall.jl or in julia-vscode. Since the segfault only happens within VSCode's Julia REPL (or a connected terminal), let's start here. To reproduce,

using Pkg
Pkg.add("RCall")
using RCall

R"install.packages('sf')"
R"library(sf)"

makes the REPL in VSCode disappear. There is no server trace info. If I open an external REPL and connect it, I can see that there is a segfault when Julia ends. This runs smoothly if I run in a REPL independent of VSCode (not even "connected" to VSCode).

I am on OSX, with Julia 1.6, R 4.1.0. Please let me know if I can provide any more debugging info.

[pfitzseb]

Can you check whether ENV is the same in a Julia session started in VSCode and a "normal" one? Also, what happens when you start VSCode from a terminal?

[ianfiske]

Thanks for the quick response!

Can you check whether ENV is the same in a Julia session started in VSCode and a "normal" one?

No they are not the same. I just tried a few things. Saved off the ENV from the working session. Then loaded all vals in from that into the VScode julia repl. Same crash.

The PATH is the only environment variable that I noticed was different which I'd think would have an impact here. There is no LD_LIBRARY_PATH or anything like that. I tried just setting PATH like in the working session, but that crashes too (which isn't surprising since loading all vals from the working session included this one).

Also, the crash happens even if I open an external bash terminal and "connect" it to VSCode. So the environment should be unchanged, yet this causes loading sf to segfault.

Also, what happens when you start VSCode from a terminal?

I tried this and still got the segfault.

[ianfiske]

I finally got around to hooking up lldb with julia-debug, reproduced the segfault. Here's the stacktrace: https://gist.github.com/ianfiske/c18cc4c2dd64f45922b40a7c7f536732

[pfitzseb]

Hm. Is it possible that Julia loads a different libc++ in VSCode and the REPL or something like that?

rstudio/reticulate#723 also looks vaguely similar...

Also, are your Julia sessions multithreaded? What happens if you run something like

using Pkg
Pkg.add("RCall")
using RCall

@async begin
  R"install.packages('sf')"
  R"library(sf)"
end

in a normal Julia session?

[ianfiske]

I think you are onto something with multithreading being the problem.

@async begin
   R"library(sf)"
end

caused a segfault in a process completely independent of VSCode. So multithreading may be the culprit after all. Unfortunately, I change my VSCode "Julia: Num Threads" to 1 (and verified with Threads.nthreads() that it worked) and it still crashes from VSCode. Is there some kind of internal multithreading to julia extension that may be causing the issue?

[pfitzseb]

Those two questions were largely independent :)
So apparently calling R"library(sf)" in a different task causes issues. Unfortunately I'm not sure I can help much more with the issue; it probably makes the most sense to open one at https://github.com/JuliaInterop/RCall.jl.

And just to follow up on the possible libstdc++ versioning issue I mentioned above: JuliaInterop/RCall.jl#272 (comment).

[ianfiske]

Thank you for the suggestions, @pfitzseb. I opened up an issue in RCall as you suggested.

Also, I tried to adapt the solution you linked for the libstd++ from Linux to OSX, I still got the segfault, though I'm unsure if I adapted the solution properly:

 $ DYLD_INSERT_LIBRARIES=/usr/lib/libstdc++.6.dylib julia --project=/Users/ifiske/julia-testing/rcall-sf-vscode                                                          
               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.6.2 (2021-07-14)
 _/ |\__'_|_|_|\__'_|  |  Official https://julialang.org/ release
|__/                   |

julia> using RCall

julia> @async begin
           R"library(sf)"
       end
[1]    88698 segmentation fault  DYLD_INSERT_LIBRARIES=/usr/lib/libstdc++.6.dylib 

[pfitzseb]

I suspect there's not much we can do about this on our end.