Repository navigation
Figure does not show without explicit plt.show() #609
Description
Activity
I had similar problems and downgrading
ipykernelto<7made those issues go away.@jokasimr Thank you very much for this hint!
I downgraded
ipykernelto6.3.1on two different machines / setups and could create hundreds of plots without triggering this issue. So whereas the outcome of this is only visible inipymplthe cause is does not seem to be tied to any recent change ifipymplbut toipykernelwhich has a number of changes regarding matplotlib in the recent releases.As far as I can tell, ipympl has historically suffered from occasionally not displaying plots, presumably due to some race condition. It is possible that the timing changes in ipykernel 7 due to different threads, etc, make the race condition more likely.
One thing you can try is to disable the use of "Kernel comms over subshells" via JupyterLab Settings Editor. The screenshot below shows the default setting, try making it Disabled and see if that makes any difference.
Reacted by Clemens Schmid@ianthomas23 Thank you for looking into this!
I tested with an
ipykernel==7.1.0by generating tens of figures again. With "Kernel Comms over subshells" set to "One subshell per comm-target" after a few figures first the figure does not show up and the output only comprises of[<matplotlib.lines.Line2D at 0x198034cc690>]. When re-executing the cell again the kernel appears to have crashed or stalled, only showing the*and not continuing with the next cell. At this point only a restart helps.When setting "Kernel Comms over subshells" to disabled the error goes away completely. Plots show up and the kernel does not stall or crash.
Reacted by Clemens Schmid@asteppke Thanks for checking.
So the recommended workaround is to disable use of "Kernel comms over subshells" whilst this is investigated further.
Bad news from me: I did disable use of "Kernel comms over subshells" and although things worked for a bit longer, I still eventually got into a state where every cell claimed it was busy, nothing was making progress, and even interrupting and restarting the kernel did not help. Restarting JupyterLab itself was necessary, which in my setup means shutting down and respawning the Lab container.
I strongly suspect there's a nasty race condition somewhere down in the threading code.
Reacted by Clemens Schmid- added a commit that references this issue
on Jul 23, 2026 I think I have the root cause for this.
ipykernel 7 fires IPython's post_execute event while handling a comm_msg on a subshell, under the comm_msg's parent header. flush_figures runs there, displays the queued figure with parent_header pointing at the comm_msg instead of the cell's execute_request, and the frontend — which routes output to cells by that id — drops it. The queue is then empty, so the cell's own post_execute displays nothing.
That fits the symptoms reported here: the first figure of a session is fine, a figure already on screen keeps a comm busy so the next one disappears, it is more likely with slower cells, and %matplotlib inline is unaffected because it creates no comms.
Minimal reproducer with no matplotlib involved, plus 7.3.0-vs-6.31.0 traces: ipython/ipykernel#1564
Workarounds that fixed it for me: pip install "ipykernel<7", or set Settings -> Kernels -> Kernel Comms over subshells to Disabled in JupyterLab.
If ipykernel considers this behaviour intended, ipympl could work around it by capturing the parent at figure-creation time, or by skipping the flush when post_execute fires outside an execute_request.
Report
Under some circumstances when using
ipymplthe figure does not show up in the output area unlessplt.show()is explicitly called.At the moment the reproduction is a bit finicky. As a minimal example these cells, when executed once show a nice empty plot:
When changing the line to read a more complex dataset
df = pd.read_csv(file_with_1MB)the empty figure sometimes does not show up anymore. If I add an explicitplt.show()at the end the figure always appears as normal.It is not directly tied to the larger data file though, even the example above sometimes shows the same behavior after the second cell is re-executed several times. When using
%matplotlib inlineno issues or errors occur.I am somewhat certain that this behavior is a regression, as it was not occurring in earlier versions of the Jupyterlab/ipympl ecosystem (with Jupyterlab/ipympl older than approximately six months ago).
Any hints how to debug this a bit better would be appreciated.
Versions
This issues occurs with a recent jupyterlab / ipympl installation (and using Chrome 142.0.7444.60). Here, this is on Windows 11 but the issue also occurs on Linux systems.