Jupyter crashes when using PyPlot and Julia 1.12

General Usage
1

Hi,
I don’t know why, but since I upgraded to julia 1.12 from 1.11 i most often get jupyter to simply crash when starting to load packages. Sometimes even the very first cell with simply

using PyPlot
already crashes
[36275] signal 11 (1): Segmentation fault
in expression starting at none:1
and I’ve tried everything to no avail. But by restarting the kernel two or more times, even turning everything off and on again, I may get it to work. Needless to say, in the REPL the same thing always works. I’ve completely removed julia and erased .julia to start from scratch, and that keeps happening. I’m working in ubuntu.ate 25.10, btw.
I wonder if anybody else has such experience, and if there’s a way to correct that. Right now is pretty irritating…
Thanks for your help.

2

What is the output of:

versioninfo()

I encountered crashes with PyPlot, mainly when the wrong C++ library was loaded. This often occurs when the LD_LIBRARY_PATH variable is not empty.

In addition, rebuilding PyCall might help:

ENV["PYTHON"]=""
Pkg.build("PyCall")

Finally, Julia 1.12 uses more than one thread by default, which is not compatible with PyPlot. So launching Julia with:

julia -t 1

might also help.

PythonPlot might be compatible with multi-threading.

3

Hi,
thanks for the help. The output of versioninfo() is:

Julia Version 1.12.3
Commit 966d0af0fdf (2025-12-15 11:20 UTC)
Build Info:
Official https://julialang.org release
Platform Info:
OS: Linux (x86_64-linux-gnu)
CPU: 32 × Intel(R) Core™ i9-14900K
WORD_SIZE: 64
LLVM: libLLVM-18.1.7 (ORCJIT, alderlake)
GC: Built with stock GC
Threads: 8 default, 1 interactive, 8 GC (on 32 virtual cores)
Environment:
JULIA_NUM_THREADS = 8

(I’ve tried reducing from 16 to 8 threads), and LD_LIBRARY_PATH is empty.
But I’ve noiticed that the crash also happens when loading other modules, even others made by myself that did work well in the same machine and OS version with previous julia releases (up to 1.11.whatever)…

4

Can you try with julia -t 1

?

And what is the output of:

using Pkg
Pkg.status()

?

5

Thanks @ufechner7 for pointing that out (link: Julia 1.12 Highlights / New multi-threading features) and thanks @Ferran_Mazzanti for posting the issue here.

I also experience julia 1.12 kernel crashes in Jupyterlab when calling using PyPlot.

Here is the output of versioninfo() when the Julia kernel is launched with the default kernelspec file (the one created by IJulia I guess):

Julia Version 1.12.5
Commit 5fe89b8ddc1 (2026-02-09 16:05 UTC)
Build Info:
  Official https://julialang.org release
Platform Info:
  OS: Linux (x86_64-linux-gnu)
  CPU: 8 × 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
  WORD_SIZE: 64
  LLVM: libLLVM-18.1.7 (ORCJIT, tigerlake)
  GC: Built with stock GC
Threads: 1 default, 1 interactive, 1 GC (on 8 virtual cores)

And indeed, to make PyPlot work, the last line needs to be instead:

Threads: 1 default, 0 interactive, 1 GC (on 8 virtual cores)

Here is my modified kernelspec file (kernel.json which is in Jupyter Data files folder, e.g. on Linux ~/.local/share/jupyter/kernels/julia-1.12)

{
  "display_name":"Julia 1.12",
  "argv":[
    "/home/pierre/.julia/juliaup/julia-1.12.5+0.x64.linux.gnu/bin/julia",
    "-i",
    "--threads=1,0",
    "--color=yes",
    "--project=@.",
    "-e",
    "import IJulia; IJulia.run_kernel()",
    "{connection_file}"
  ],
  "language":"julia",
  "env":{},
  "interrupt_mode":"signal"
}

The only modification to the preexisting kernel is the item "--threads=1,0" added to the argv list.

6

I think I also encounter some issues with PyPlot on 1.12.

7

Easy to avoid: Start Julia with:

julia -t 1,0 <other arguments>

or use PythonPlot.jl.

8

Thank you guys. That solves the problem.

9

The -t 1 solution works, but I have a notebook about mutlithreaded computing and the whole point is to illustrate that using threads is a good thing. I thought this problem had gone away but it is back. PythonPlot solves the problem but telling my users to put

ENV["JULIA_CONDAPKG_VERBOSITY"] = "0"
ENV["JULIA_CONDAPKG_LOG"] = "warn"

to avoid the pointless messages from CondaPkg will be a pain for those who do not know what a startup.jl file is.

10

I agree. PythonCall checks for updates far too often. That’s why I still use PyPlot. Perhaps we should create an issue?

11

I am about to do that for PythonPlot. It seems that PyPlot has problems with every new release.

12

Try putting ENV[“JULIA_CONDAPKG_VERBOSITY”] = “-1”
in your startup.jl file. That seems to be working for me.
ENV[“JULIA_CONDAPKG_VERBOSITY”] = “-1”

ENV[“JULIA_CONDAPKG_VERBOSITY”] = "-1"ENV[“JULIA_CONDAPKG_VERBOSITY”] = “-1”

ENV[“JULIA_CONDAPKG_VERBOSITY”] = “0”

13

It’s a bit worse than that. After fighting ChatGPT for an hour. This seems to work. The problem is the pixi backend.

ENV["JULIA_CONDAPKG_VERBOSITY"] = "-1"
ENV["JULIA_CONDAPKG_LOG"] = "error"
ENV["JULIA_CONDAPKG_BACKEND"] = "MicroMamba"

and then put a semicolon after using PythonPlot

I also seemed to need to cleanup some old files with

rm -rf ~/.julia/environments/v1.12/.CondaPkg
rm -rf ~/.julia/environments/v1.13/.CondaPkg

This seems to work but I’ve had inconsistent results with all these fixes. Sometimes I get three lines about dependencies

julia> using PythonPlot;
    CondaPkg Found dependencies: /Users/ctk/.julia/packages/CondaPkg/8GjrP/CondaPkg.toml
    CondaPkg Found dependencies: /Users/ctk/.julia/packages/PythonCall/83z4q/CondaPkg.toml
    CondaPkg Found dependencies: /Users/ctk/.julia/packages/PythonPlot/oS8x4/CondaPkg.toml
    CondaPkg Dependencies already up to date

but most of the time I do not. YMMV.

I raised an issue with CondaPkg.

Suppress dependency lines · Issue #216 · JuliaPy/CondaPkg.jl · GitHub)