I cant make
JavaCall.init() work from a julia session started by the VSCode plugin.
Same as for this post RCall vscode REPL crash, it works fine if I do it from a terminal.
I have tried on two different machines, with 1.6, 1.7, and 1.8
Here is how to reproduce the problem:
- Create a new project
- Add dependency to JavaCall
- Start a julia session from VSCode
- Execute the following:
The julia extension version is v1.38.2
VSCode version is 1.74.2
If I activate the tmux persistent session, the only additional information that I get is the following:
Pane is dead (signal 11, Thu Jan 5 15:13:44 2023)
Just tmux telling the pane in which the julia session runs is dead
What operating system are you using?
I’m using linux Fedora 37
$ java --version
openjdk 17.0.5 2022-10-18
OpenJDK Runtime Environment (Red_Hat-126.96.36.199.8-1.fc37) (build 17.0.5+8)
OpenJDK 64-Bit Server VM (Red_Hat-188.8.131.52.8-1.fc37) (build 17.0.5+8, mixed mode, sharing)
I will try with an Oracle JRE and tell how it goes
same when using the oracle jvm
I’m not sure if I have tested JavaCall.jl with a JVM beyond Java 11, so you might try downgrading if possible.
My suspicion is that we are running into issues with signals and signal chaining. Some of it could actually be ignored if we could catch it before it becomes fatal.
My recommendation would be to try some kind of message passing and IPC instead. For example, ZMQ and Apache Arrow.
I’m running an Ubuntu 22.04 box.
To obtain a environment we both can run, I did the following:
Download mamba-forge from here:
GitHub - conda-forge/miniforge: A conda-forge distribution.
Create an environment using mamba with the following incantation.
mamba create -n julia185_java17 -c conda-forge julia=1.8.5 openjdk=17
mamba activate julia185_java17
- Invoke julia with
$ JULIA_COPY_STACKS=1 julia
- Run the following in the Julia REPL.
julia> using Pkg
julia> pkg"add JavaCall"
Resolving package versions...
No Changes to `~/mambaforge/envs/julia185_java17/share/julia/environments/julia185_java17/Project.toml`
No Changes to `~/mambaforge/envs/julia185_java17/share/julia/environments/julia185_java17/Manifest.toml`
julia> using JavaCall
julia> jls = @jimport java.lang.System
julia> jcall(jls, "getProperty", JString, (JString,), "java.version")
julia> out = jfield(jls, "out", @jimport java.io.PrintStream)
julia> jcall(out, "println", Nothing, (JString,), "Hello World from Julia 1.8.5 and Java 17")
Hello World from Julia 1.8.5 and Java 17
Hi, sorry for my late reply.
I had issues with mambaforge, so I wasnt able to do what you wanted me to.
But I have tried on 3 different linux machines and on one Windows machine.
It fails for all linux machines but not for the windows machine.
On linux the problem happens only when using vscode.
Regarding your last question, I thought the tittle of the discussion and my first message didnt lead to confusion, but let me say it again:
We only have the problem with a julia session started by VSCode julia extension (Open Palettte > Julia:Start REPL)
We tried with openJDK JREs and oracle JREs, on Ubuntu, Debian, Fedora.
Last try was with openjdk version “17.0.5” 2022-10-18 on Fedora 37
The issue with mamba-forge is that on my local environment it messed up my env, I uninstalled it and with remote containerized dev, Im not sure how to achieve that.
Did you set the environment variable
JULIA_COPY_STACKS=1 before starting VSCode?
I still cannot reproduce this on Ubuntu 22.04. I just tried again in from the Julia REPL in VSCode without an issue.
openjdk version "11.0.17" 2022-10-18
OpenJDK Runtime Environment (build 11.0.17+8-post-Ubuntu-1ubuntu222.04)
OpenJDK 64-Bit Server VM (build 11.0.17+8-post-Ubuntu-1ubuntu222.04, mixed mode, sharing)
that is really strange, that’s what I have
JULIA_COPY_STACKS in my startup.jl
let me try setting it as a user environment variable
No, that is not sufficient to set in startup.jl. You must set the environment variable before the Julia process starts.
that was the problem,
JULIA_COPY_STACKS cannot be set in startup.jl if the julia session is started by vscode,
I’m glad we eventually got this solved. One hint for me was that you were having more issues on Linux than Windows.
To elaborate, the issue is due to interference between task context switching and intraprocess signalling. Java and Julia both use signals, such as SIGSEGV and SIGTERM, and install signal handlers. If the wrong signal handler catches the signal or the signal handler does not exist in the current stack as expected, a segmentation fault (signal 11) can occur. The situation continues to be quite fragile.
You may also want to consider running Java and Julia in different processes and communicating using an interprocess communication (IPC) protocol such as ZeroMQ and shared memory (Apache Arrow).