Julia session crashes when calling `JavaCall.init()` from a julia session managed by VSCode

Tooling VS Code
,
1

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:
using JavaCall
JavaCall.init()

The julia extension version is v1.38.2
VSCode version is 1.74.2

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

3

What operating system are you using?

4

I’m using linux Fedora 37

5

Which JVM are you using?

6 
$ java --version
openjdk 17.0.5 2022-10-18
OpenJDK Runtime Environment (Red_Hat-17.0.5.0.8-1.fc37) (build 17.0.5+8)
OpenJDK 64-Bit Server VM (Red_Hat-17.0.5.0.8-1.fc37) (build 17.0.5+8, mixed mode, sharing)

I will try with an Oracle JRE and tell how it goes

7

same when using the oracle jvm

8

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.

9

I’m running an Ubuntu 22.04 box.

To obtain a environment we both can run, I did the following:

  1. Download mamba-forge from here:
    GitHub - conda-forge/miniforge: A conda-forge distribution.

  2. 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
  1. Invoke julia with JULIA_COPY_STACKS=1:
$ JULIA_COPY_STACKS=1 julia
  1. 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> JavaCall.init()

julia> jls = @jimport java.lang.System
JavaObject{Symbol("java.lang.System")}

julia> jcall(jls, "getProperty", JString, (JString,), "java.version")
"17.0.3-internal"

julia> out = jfield(jls, "out", @jimport java.io.PrintStream)
JavaObject{Symbol("java.io.PrintStream")}(JavaCall.JavaLocalRef(Ptr{Nothing} @0x0000559d3590e310))

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
10

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.

11

Could you elaborate?

  1. What was the problem with mamba-forge?
  2. What version of Java are you trying on each machine?
  3. Did you try anything other than Java 17?
  4. Where did you download Java from? Have you treid Azul Zulu JDK?
  5. If you start a terminal within VSCode, start julia from the terminal, and then use JavaCall do you still encounter the problem?
12

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.

13

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)

image
image1572×481 40 KB

14

that is really strange, that’s what I have

image
image1173×656 69.9 KB

15

I set JULIA_COPY_STACKS in my startup.jl

let me try setting it as a user environment variable

16

No, that is not sufficient to set in startup.jl. You must set the environment variable before the Julia process starts.

17

that was the problem, JULIA_COPY_STACKS cannot be set in startup.jl if the julia session is started by vscode,

Thanks!

1 Like
18

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