JuliaCall fails with segmentation fault (core dumped)

[jalcam]

I have Julia installed with Juliaup (1.10 and 1.11). When I try to setup juliacall in R with 1.10 I get a segfault:

> library(JuliaCall)
> julia_setup(JULIA_HOME = "/home/juanjose/.julia/juliaup/julia-1.10.6+0.x64.linux.gnu/bin")
Julia version 1.10.6 at location /home/juanjose/.julia/juliaup/julia-1.10.6+0.x64.linux.gnu/bin will be used.
Loading setup script for JuliaCall...
Segmentation fault (core dumped)

when I try with Julia 1.11 the error is:

> library(JuliaCall)
> julia_setup(JULIA_HOME = "/home/juanjose/.julia/juliaup/julia-1.11.1+0.x64.linux.gnu/bin")
Julia version 1.11.1 at location /home/juanjose/.julia/juliaup/julia-1.11.1+0.x64.linux.gnu/bin will be used.
Error in juliacall_initialize(.julia$dll_file, .julia$bin_dir, img_abs_path) : 
  jl_stdout_obj - /home/juanjose/.julia/juliaup/julia-1.11.1+0.x64.linux.gnu/bin/../lib/libjulia.so.1.11: undefined symbol: jl_stdout_obj

In Julia I've tried:

julia> using RCall

julia> RCall.Rhome
"/usr/lib/R"

julia> RCall.libR
"/usr/lib/R/lib/libR.so"

julia> RCall.validate_libR(RCall.libR)
true

julia> ENV["R_HOME"] = "/usr/lib/R"
"/usr/lib/R"

julia> Pkg.build("RCall")
    Building Conda → `~/.julia/scratchspaces/44cfe95a-1eb2-52ea-b672-e2afdf69b78f/b19db3927f0db4151cb86d073689f2428e524576/build.log`
    Building RCall → `~/.julia/scratchspaces/44cfe95a-1eb2-52ea-b672-e2afdf69b78f/db17ec90d9f904b79e7877a764fdf95ff5c5f315/build.log`

But the segfault persists when trying JuliaCall

[ViralBShah]

Do you have something in your LD_LIBRARY_PATH or DYLD_LIBRARY_PATH or LD_PRELOAD?

[jalcam]

Do you have something in your LD_LIBRARY_PATH or DYLD_LIBRARY_PATH or LD_PRELOAD?

I have this:

> echo $LD_LIBRARY_PATH
/opt/openfoam12/thirdparty/platforms/linux64Gcc/gperftools-svn/lib:/usr/lib/x86_64-linux-gnu:/opt/openfoam12/platforms/linux64GccDPInt32Opt/lib/paraview-5.11:/opt/openfoam12/platforms/linux64GccDPInt32Opt/lib/openmpi-system:/opt/openfoam12/thirdparty/platforms/linux64GccDPInt32/lib/openmpi-system:/usr/lib/x86_64-linux-gnu/openmpi/lib:/home/jalcam/OpenFOAM/jalcam-12/platforms/linux64GccDPInt32Opt/lib:/opt/site/12/platforms/linux64GccDPInt32Opt/lib:/opt/openfoam12/platforms/linux64GccDPInt32Opt/lib:/opt/openfoam12/thirdparty/platforms/linux64GccDPInt32/lib:/opt/openfoam12/platforms/linux64GccDPInt32Opt/lib/dummy

> echo $DYLD_LIBRARY_PATH

> echo $LD_PRELOAD 

I use OpenFoam in the same computer.

[ViralBShah]

Can you unset that variable and see if it still crashes?

[jalcam]

Can you unset that variable and see if it still crashes?

I have unset the variable now:

> echo $LD_LIBRARY_PATH

But I'm getting the same error:

> library(JuliaCall)
> julia_setup(JULIA_HOME = "/home/juanjose/.julia/juliaup/julia-1.10.6+0.x64.linux.gnu/bin")
Julia version 1.10.6 at location /home/juanjose/.julia/juliaup/julia-1.10.6+0.x64.linux.gnu/bin will be used.
Loading setup script for JuliaCall...
Segmentation fault (core dumped)

[marc-milgrom-ncl]

I have downloaded Chris's latest patch branch, and devtools:check seg faults on 1.11. When I override it to build with JULIA_HOME set to the latest 1.9 release, it builds, but then julia_setup causes R to seg fault.
I'm running R 4.4.2 ETA: on Ubuntu 24.04.1 LTS. (Under WSL2 if that matters?)

[marc-milgrom-ncl]

I think I'm making progress here. julia_setup is failing, and I see this:

julia> Libdl.dlopen("/usr/local/lib/R/library/methods/libs/methods.so")
ERROR: could not load library "/usr/local/lib/R/library/methods/libs/methods.so"
libR.so: cannot open shared object file: No such file or directory
Stacktrace:
 [1] dlopen(s::String, flags::UInt32; throw_error::Bool)
   @ Base.Libc.Libdl ./libdl.jl:117
 [2] dlopen
   @ ./libdl.jl:116 [inlined]
 [3] dlopen(s::String)
   @ Base.Libc.Libdl ./libdl.jl:116
 [4] top-level scope
   @ REPL[2]:1

The methods package is installed, but I had a similar error with libRblas.so until I rebuilt R with the with-blas option. It seems like JuliaCall is expecting all the R libraries to be statically linked into libR.so or something? It's not possible to build R that way to my knowledge.

[ViralBShah]

How was the R you are using built and installed? This may be an issue with some LD_LIBRARY_PATH type setting.

I always wanted R in Yggdrasil, but IIRC, it does not support cross compilation. But maybe we can just package the upstream binaries like we do for MKL. And at least that way, we can have something that works reliably.

[marc-milgrom-ncl]

I don't have any LD_LIBRARY_PATH set, but I tried setting ENV["LD_LIBRARY_PATH"]="/usr/local/lib:/usr/local/lib/R/library" in Julia before running setup.jl to no avail.
I built R from the current 4.4.2 release source with:

sudo ./configure --enable-R-shlib --enable-memory-profiling  --with-blas --prefix=/usr/local

and then sudo make and sudo make install.

To be clear I only built it from source to enable debugging of the segmentation fault I was having with the packaged R binaries, which are stripped. This didn't help as R -d gdb isn't catching the SEGV, I think because it's actually in Julia, not R, but that's a guess.

[ViralBShah]

Is methods.so coming from JuliaCall or from R? The issue with methods.so seems to do with resolving all the dependencies for the shared library.

[marc-milgrom-ncl]

The methods.so library comes from methods, one of the expected R packages called by RCall from Julia. It happens to be one of the recommended packages included in the standard R build, i.e. unless -without-recommended-packages is specified to configure.

[marc-milgrom-ncl]

I was about to test if building R without the recommended packages and then installing them after build and install would change the behavior, but it's now 17:30 here so I'll pick this up tomorrow.

[ViralBShah]

Is there an issue with 1.10 too?

[marc-milgrom-ncl]

It also SEGV'd the last time I tried it, but that might have been with the packaged R binaries so not necessarily the same issue.

[simonbeyer1]

I had the exact same problem yesterday. Downgrading to Ubuntu 22.04.5 LTS (Jammy Jellyfish) solved the issue for me.

[marc-milgrom-ncl]

Thanks. I'll spin up a 22 VM and see if that works.

[marc-milgrom-ncl]

I tried a bog standard Ubuntu 22 distro adding only r-base, r-base-dev, and the system libraries needed to build devtools, and Julia 1.11. The output from devtools::check() for the latest JuliaCall repo is:
❯ checking tests ...
See below...

❯ checking compiled code ... OK
WARNING
‘qpdf’ is needed for checks on size reduction of PDFs

❯ checking for future file timestamps ... NOTE
unable to verify current time

❯ checking for detritus in the temp directory ... NOTE
Found the following files/directories:
‘jl_e2VIEf’

── Test failures ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── testthat ────

library(testthat)
library(JuliaCall)

test_check("JuliaCall")
Error: object 'aaa' not found
Error: object 'aaa' not found
Error in sqrt("aaa") : non-numeric argument to mathematical function
test (generic function with 1 method)

1.4142135623730951

1.4142135623730951

free(): invalid size

[47650] signal 6 (-6): Aborted
in expression starting at none:0
pthread_kill at /usr/lib/x86_64-linux-gnu/libc.so.6 (unknown line)
raise at /usr/lib/x86_64-linux-gnu/libc.so.6 (unknown line)
abort at /usr/lib/x86_64-linux-gnu/libc.so.6 (unknown line)
unknown function (ip: 0x7f10dee18675)
unknown function (ip: 0x7f10dee2fcfb)
unknown function (ip: 0x7f10dee31a53)
free at /usr/lib/x86_64-linux-gnu/libc.so.6 (unknown line)
malloc(): unaligned tcache chunk detected
Aborted (core dumped)

1 error ✖ | 1 warning ✖ | 2 notes ✖

[ViralBShah]

How about with Julia 1.10?

[marc-milgrom-ncl]

check() runs ok with 1.10, and the package seems to function.
So there seem to be issues with both Ubuntu 24 and Julia 1.11.

[jalcam]

I have installed R on Ubuntu 24.04 using binaries via https://eddelbuettel.github.io/r2u/. Could it have something to do with it? I think it should work with Julia 1.10 anyway but the segfault persists

[marc-milgrom-ncl]

As far I can I, and the commenter above, can tell, Ubuntu 24 is incompatible with JuliaCall. It will not build with julia 1.10 or 1.11, and while it seemed to build with 1.9, it segfaulted as soon as I attempted to run it.

[edwardlavender]

I experienced the same issue on Ubuntu 24.04.1 LTS with Julia 1.11 and Julia 1.10.5. I haven't tried downgrading Ubuntu version.

# > library(JuliaCall)
# > julia_setup(rebuild = TRUE, force = TRUE)
# Julia version 1.10.5 at location /home/edward/.julia/juliaup/julia-1.10.5+0.x64.linux.gnu/bin will be used.
# Loading setup script for JuliaCall...
# Segmentation fault (core dumped)

[trafficfan]

> library(JuliaCall)
> julia_setup()
Julia version 1.11.2 at location C:\Users\admin\.julia\juliaup\julia-1.11.2+0.x64.w64.mingw32\bin will be used.
Loading setup script for JuliaCall...
错误于.julia$cmd(paste0(Rhomeset, "Base.include(Main,\"", system.file("julia/setup.jl", : 
  Error happens when you try to execute command ENV["R_HOME"] = "C:/PROGRA~1/R/R-devel";Base.include(Main,"C:/Users/admin/AppData/Local/R/win-library/4.5/JuliaCall/julia/setup.jl") in Julia.
                        To have more helpful error messages,
                        you could considering running the command in Julia directly

I meet the same issue on win11,could someone help?

[mkitti]

library(JuliaCall)\n> julia_setup()\nJulia version 1.11.2 at location C:\Users\admin\.julia\juliaup\julia-1.11.2+0.x64.w64.mingw32\bin will be used.\nLoading setup script for JuliaCall...\n错误于.julia$cmd(paste0(Rhomeset, "Base.include(Main,\"", system.file("julia/setup.jl", : \n Error happens when you try to execute command ENV["R_HOME"] = "C:/PROGRA~1/R/R-devel";Base.include(Main,"C:/Users/admin/AppData/Local/R/win-library/4.5/JuliaCall/julia/setup.jl") in Julia.\n To have more helpful error messages,\n you could considering running the command in Julia directly\nI meet the same issue on win11,could someone help?

This does not seem like the same error on win11 Could you create another issue?

[keithmcnulty]

Just upgraded my EC2 to Ubuntu 24 today and and seeing the same issue with JuliaCall with Julia 1.11, 1.10 - also went back to 1.6. Does indeed seem to be an Ubuntu 24 issue.

[mkitti]

How are you installing R?

[keithmcnulty]

How are you installing R?

sudo apt install --no-install-recommends r-base latest version (4.4.2) from CRAN's repositiories.

I have reinstalled everything on Ubuntu 22 and all works smoothly, so does seem to be some issue with Ubuntu 24.

[mkitti]

I wonder if it would make sense to install R via conda-forge or other means. Otherwise, we may need to prepend Julia's libraries to the LD_LIBRARY_PATH.

[mlechu]

This seems to be an LD_LIBRARY_PATH issue combined with a bad version of libunwind. In particular:

• Running R as packaged from apt uses a wrapper shell script (/usr/bin/R) which starts the real R binary (/usr/lib/R/bin/exec/R) after setting a bunch of environment variables, notably adding /usr/lib/x86_64-linux-gnu to LD_LIBRARY_PATH for some reason. This is why changing LD_LIBRARY_PATH before starting R is ineffective.
• Julia then loads libunwind.so.8 from /usr/lib/x86_64-linux-gnu/ instead of from julia (e.g. /home/user/.julia/juliaup/julia-1.11.3+0.x64.linux.gnu/bin/../lib/julia/). apt info libunwind8 shows Version: 1.6.2-3build1 about the system package.
• Julia does prepare for segfaults from libunwind, but when I load libunwind 1.6.2, it uses sigprocmask to make the segfault handler ineffective (right before segfaulting). More investigation is needed into what the actual bug is, but 1.6.2 also gives us a segmentation fault in plain Julia (MWE: julia -e "foo(n) = n > 0 ? foo(n-1) : [1,2,3][4]; foo(10)", thanks @topolarity!) Also, ubuntu 22's default libunwind8 (1.3.2-2build2.1) doesn't have this issue.
  • edit: Possibly be related to Regression after pre-linked libraries change libunwind/libunwind#637

The environment variables used are the ones set when R starts, so JuliaCall can't fix this by unsetting or prepending to LD_LIBRARY_PATH. (Admittedly I did try.)

Workaround

If you need to get JuliaCall working now, you can either preload correct libunwind, e.g.

LD_PRELOAD="/home/user/.julia/juliaup/julia-1.11.3+0.x64.linux.gnu/lib/julia/libunwind.so.8" R

or write a new R wrapper script similar to /usr/bin/R that doesn't set LD_LIBRARY_PATH.

#!/bin/bash
# subset of the shell wrapper for R executable.

R_HOME=/usr/lib/R
export R_HOME
R_SHARE_DIR=/usr/share/R/share
export R_SHARE_DIR
R_INCLUDE_DIR=/usr/share/R/include
export R_INCLUDE_DIR
R_DOC_DIR=/usr/share/R/doc
export R_DOC_DIR
exec /usr/lib/R/bin/exec/R

[topolarity]

edit: Possibly be related to libunwind/libunwind#637

Yeah, confirmed this - the issue bisects to exactly the same change

[nalimilan]

Good catch! So to me it seems that the R wrapper scripts used by some distributions are bad citizens as they set LD_LIBRARY_PATH, which is generally a recipe for problems. FWIW Fedora doesn't seem to do this so there are other solutions. Maybe we should report this to Ubuntu?

[jalcam]

I have installed R on Ubuntu 24.04 using binaries from this source. These binaries are not maintained by Ubuntu. My LD_LIBRARY_PATH is empty.

[mkitti]

@jalcam , have you tried setting LD_PRELOAD as in #238 (comment) ?