# PyPlot Crash

**URL:** <https://discourse.julialang.org/t/pyplot-crash/1706>\
**Category:** General Usage\
**Tags:** plotting, pyplot\
**Created:** [January 26, 2017, 6:27pm UTC](https://discourse.julialang.org/t/pyplot-crash/1706 "2017-01-26T18:27:58Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![goldfita](https://avatars.discourse-cdn.com/v4/letter/g/4491bb/32.png) [@goldfita](https://discourse.julialang.org/u/goldfita)\
**Post date:** [January 26, 2017, 6:27pm UTC](https://discourse.julialang.org/t/pyplot-crash/1706/1 "2017-01-26T18:27:58Z")

</div>

The following stem plot takes around half a minute to execute, all the while the REPL is blocked. I thought either PyPlot was supposed to automatically run plotting asynchronously in the background or at least there is supposed to be a way to do it; however, I could not figure out how to get it to work. The more relevant issue is that if I try to close the plot while it’s processing, it crashes Julia. At least once it gave me a strange error due to only clicking on the window, but usually it recovers from this.

Since I assume somewhere underneath there is a broken C call, I haven’t posted this as a bug. But I thought maybe there is a more graceful way to fail. Or it would be even better if it would run asynchronously and I would have less reason to attempt to stop it when it’s taking too long.

```julia
using PyPlot
stem(randn(32768))

versioninfo()
Julia Version 0.5.0
Commit 3c9d753 (2016-09-19 18:14 UTC)
Platform Info:
  System: NT (x86_64-w64-mingw32)
  CPU: Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.7.1 (ORCJIT, broadwell)

```

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [January 26, 2017, 6:46pm UTC](https://discourse.julialang.org/t/pyplot-crash/1706/2 "2017-01-26T18:46:04Z")

</div>

> [@goldfita](#):
>
> using PyPlot  
> stem(randn(32768))

Does it work in Python? If not, it might be a bug in Matplotlib.

---

<div class="post-metadata">

**Author:** ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)\
**Post date:** [January 26, 2017, 7:01pm UTC](https://discourse.julialang.org/t/pyplot-crash/1706/3 "2017-01-26T19:01:00Z")

</div>

I don’t know if it’s related, but before the ColorTypes.jl [got broken](https://github.com/JuliaGraphics/ColorTypes.jl/issues/65) on master (and hence breaking everything based on it; I’m enjoying [UnicodePlots.jl](https://github.com/Evizero/UnicodePlots.jl) these days), I ran into this problem with PyPlot: [https://github.com/JuliaPy/PyPlot.jl/issues/269](https://github.com/JuliaPy/PyPlot.jl/issues/269) I’m not really sure it’s related to matplotlib 2.0, but that’s the only that changed on my system, that I’m aware of. I asked to other people that reported the same problem on the bug tracker what version they were running, but no one answered.

To make it clear: matplotlib works in Python and via PyPlot in Julia 0.5, it was only in Julia master that crashed.

---

<div class="post-metadata">

**Author:** ![goldfita](https://avatars.discourse-cdn.com/v4/letter/g/4491bb/32.png) [@goldfita](https://discourse.julialang.org/u/goldfita)\
**Post date:** [January 26, 2017, 7:18pm UTC](https://discourse.julialang.org/t/pyplot-crash/1706/4 "2017-01-26T19:18:03Z")

</div>

> [@stevengj](#):
>
> Does it work in Python? If not, it might be a bug in Matplotlib.

I’ve never used matplotlib in native Python. I’ve always used Matlab to do numerical computing. I started with PyPlot because that was the easiest starting point. Further, I don’t even know what version of matplotlib or python is being used.

---

<div class="post-metadata">

**Author:** ![jheinen](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jheinen/32/2787_2.png) [@jheinen](https://discourse.julialang.org/u/jheinen)\
**Post date:** [January 26, 2017, 10:24pm UTC](https://discourse.julialang.org/t/pyplot-crash/1706/5 "2017-01-26T22:24:50Z")

</div>

Same behaviour in pure Python 2.7 + matplotlib 2.0 (on macOS X 10.12). Ran for minutes and ate \>1GB of memory - no plot - I had to stop the process and `force quit` the MPL window.

Works fine (\<\< 1s) with GR (both in Python and Julia):

```julia
using GR
stem(randn(32768))

```

Probably too much data for MPL …

---

<div class="post-metadata">

**Author:** ![goldfita](https://avatars.discourse-cdn.com/v4/letter/g/4491bb/32.png) [@goldfita](https://discourse.julialang.org/u/goldfita)\
**Post date:** [January 27, 2017, 12:25am UTC](https://discourse.julialang.org/t/pyplot-crash/1706/6 "2017-01-27T00:25:34Z")

</div>

Can I use it as the backend for MPL in Julia? I set MPLBACKEND=gr, but it doesn’t appear to do anything. I can use it directly. Although it’s faster, I was having a problem with the plot not showing up the second time. I’m not familiar with how to use it however…

---

<div class="post-metadata">

**Author:** ![jheinen](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jheinen/32/2787_2.png) [@jheinen](https://discourse.julialang.org/u/jheinen)\
**Post date:** [January 27, 2017, 3:08am UTC](https://discourse.julialang.org/t/pyplot-crash/1706/7 "2017-01-27T03:08:53Z")

</div>

You can use GR as a backend for MPL:

```julia
ENV["MPLBACKEND"] = "module://gr.matplotlib.backend_gr"
using PyPlot
...

```

What was the example, that didn’t work with GR?

If you are new to Julia plotting or if you don’t want to make a decision for a specifc plotting librarary, you better should use `Plots.jl`:

```julia
using Plots
gr()
...

```

---

<div class="post-metadata">

**Author:** ![goldfita](https://avatars.discourse-cdn.com/v4/letter/g/4491bb/32.png) [@goldfita](https://discourse.julialang.org/u/goldfita)\
**Post date:** [January 27, 2017, 2:09pm UTC](https://discourse.julialang.org/t/pyplot-crash/1706/8 "2017-01-27T14:09:00Z")

</div>

> [@jheinen](#):
>
> ENV[“MPLBACKEND”] = “module://gr.matplotlib.backend\_gr”

I get the error below. I had a similar or maybe the same error when I set this variable the way you show using the windows GUI.

julia\> ENV[“MPLBACKEND”] = “module://gr.matplotlib.backend\_gr”  
“module://gr.matplotlib.backend\_gr”

julia\> using PyPlot  
ERROR: InitError: PyError (:PyImport\_ImportModule) \<type ‘exceptions.ImportError’\>  
ImportError(‘No module named gr.matplotlib.backend\_gr’,)  
File “C:\Users\goldfing\.julia\v0.5\Conda\deps\usr\lib\site-packages\matplotlib\pyplot.py”, line 114, in   
\_backend\_mod, new\_figure\_manager, draw\_if\_interactive, _show = pylab\_setup()  
File "C:\Users\goldfing\.julia\v0.5\Conda\deps\usr\lib\site-packages\matplotlib\backends\_init_.py", line 32, in pylab\_setup  
globals(),locals(),[backend\_name],0)

in pyerr\_check at C:\Users\goldfing\.julia\v0.5\PyCall\src\exception.jl:56 [inlined]  
in pyerr\_check at C:\Users\goldfing\.julia\v0.5\PyCall\src\exception.jl:61 [inlined]  
in macro expansion at C:\Users\goldfing\.julia\v0.5\PyCall\src\exception.jl:81 [inlined]  
in pyimport(::String) at C:\Users\goldfing\.julia\v0.5\PyCall\src\PyCall.jl:387  
in **init** () at C:\Users\goldfing\.julia\v0.5\PyPlot\src\PyPlot.jl:235  
in \_include\_from\_serialized(::String) at .\loading.jl:150  
in \_require\_from\_serialized(::Int64, ::Symbol, ::String, ::Bool) at .\loading.jl:187  
in \_require\_search\_from\_serialized(::Int64, ::Symbol, ::String, ::Bool) at .\loading.jl:217  
in require(::Symbol) at .\loading.jl:371  
during initialization of module PyPlot

---

<div class="post-metadata">

**Author:** ![jheinen](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jheinen/32/2787_2.png) [@jheinen](https://discourse.julialang.org/u/jheinen)\
**Post date:** [January 27, 2017, 4:46pm UTC](https://discourse.julialang.org/t/pyplot-crash/1706/9 "2017-01-27T16:46:38Z")

</div>

The GR framework must be installed within your Python environment or in a separate directory, as in our case (`S:/gr`):

```julia
ENV["MPLBACKEND"]="module://gr.matplotlib.backend_gr"
ENV["PYTHONPATH"]="S:/gr/python"

using PyPlot

x = linspace(0, 10, 200)
y = sin(x)

plot(x,y)
show()

```

I’m just thinking about adding the Python stuff to the Julia GR.jl installation. It’s just about copying some simple wrapper scripts …

---

<div class="post-metadata">

**Author:** ![goldfita](https://avatars.discourse-cdn.com/v4/letter/g/4491bb/32.png) [@goldfita](https://discourse.julialang.org/u/goldfita)\
**Post date:** [January 27, 2017, 5:27pm UTC](https://discourse.julialang.org/t/pyplot-crash/1706/10 "2017-01-27T17:27:03Z")

</div>

> [@jheinen](#):
>
> module://gr.matplotlib.backend\_gr

OK. I don’t have time to figure this out right now. Keep in mind, not everyone has the official Python installed. My Julia is using Conda for Python as you can see from the error message. I’m not sure what that actually means. I found the Python binary in C:\Users\goldfing\.julia\v0.5\Conda\deps\usr.

---

<div class="post-metadata">

**Author:** ![goldfita](https://avatars.discourse-cdn.com/v4/letter/g/4491bb/32.png) [@goldfita](https://discourse.julialang.org/u/goldfita)\
**Post date:** [January 27, 2017, 5:36pm UTC](https://discourse.julialang.org/t/pyplot-crash/1706/11 "2017-01-27T17:36:17Z")

</div>

I wanted to revisit the issue of Julia crashing. In my very limited experience, Julia seems to reliably go down when the shared library it calls into has a problem. I don’t know enough about how shared libraries work to know if this is in any way avoidable, BUT Matlab seems to reliably recover from calling into a bad mex file (just a dll) these days, although it may just be luck on my part…

The reason it matters is because sometimes you’re experimenting in the REPL, and suppose you happen to have generated a random data set that breaks your algorithm, and then you unexpectedly crash. You can’t get your data set back at that point.

---

<div class="post-metadata">

**Author:** ![jheinen](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jheinen/32/2787_2.png) [@jheinen](https://discourse.julialang.org/u/jheinen)\
**Post date:** [January 28, 2017, 2:28pm UTC](https://discourse.julialang.org/t/pyplot-crash/1706/12 "2017-01-28T14:28:02Z")

</div>

In this case, not Julia is crashing, but Python. Python could not import the GR matplotlib backend, because it simply wasn’t installed.

As mentioned before, I can easily fix this problem in Julia(!) by adding the GR Python stuff to the Julia GR run-time package, thus allowing PyPlot to be used with any Python interpreter (2.x, 3.x) installed within Julia. I’ll change this in the next release …

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [January 28, 2017, 4:58pm UTC](https://discourse.julialang.org/t/pyplot-crash/1706/13 "2017-01-28T16:58:50Z")

</div>

> [@goldfita](#):
>
> I wanted to revisit the issue of Julia crashing. In my very limited experience, Julia seems to reliably go down when the shared library it calls into has a problem. I don’t know enough about how shared libraries work to know if this is in any way avoidable, BUT Matlab seems to reliably recover from calling into a bad mex file (just a dll) these days, although it may just be luck on my part…

A subroutine call into a shared library is running in the same process and memory space as the caller, and if it crashes then the caller crashes. I don’t think there is any way around this. In this case, Python is crashing because of a Matplotlib bug (I encourage you to file a Matplotlib issue).

Matlab’s computational process crashes if a mex file crashes, too (google “mex crash matlab” and you will see lots of examples). However, IIRC its user interface runs in a separate process these days, so the user interface stays running and launches a new kernel, but of course you lose all of the variables in your workspace. The analogous thing in Julia is to run your user interface in a separate process via e.g. IJulia or Juno. In IJulia, for example, if the `julia` process crashes, then it will give you a “kernel crashed, restarting” message, but the user interface will keep running, similar to Matlab.

---

<div class="post-metadata">

**Author:** ![goldfita](https://avatars.discourse-cdn.com/v4/letter/g/4491bb/32.png) [@goldfita](https://discourse.julialang.org/u/goldfita)\
**Post date:** [January 28, 2017, 6:14pm UTC](https://discourse.julialang.org/t/pyplot-crash/1706/14 "2017-01-28T18:14:24Z")

</div>

> [@jheinen](#):
>
> In this case, not Julia is crashing, but Python. Python could not import the GR matplotlib backend, because it simply wasn’t installed.

Yes I understand this. Steven’s answer addressed my question. I had been hoping there was a way to fail gracefully without losing what I’m working on, but apparently that’s not the case.

Following instructions [here](http://gr-framework.org/installation.html), I attempted to install GR with anaconda, but it complained about an incompatibility with Python 3.5. I tried to build GR from scratch. I first had to install the MSVC 14 c++ compiler. Then I reran setup.py and failed with [this message](https://drive.google.com/file/d/0B5WhV7G7vocJNGlVOVhwMFVqWkk/view?usp=sharing).