Error with ipykernel>=7 in combination with plt.tight_layout #610

Activity

1. MartinKorz commented on Jul 17, 2026

   

   MartinKorz

   on Jul 17, 2026

   More actions

   We hit this bug and debugged it beyond the MathTextParser lock, which turned out to be insufficient

   Root cause: JupyterLab ≥ 4.4 defaults commsOverSubshells to perCommTarget, and ipykernel ≥ 7 runs each kernel subshell on its own thread. Widget comm messages — including ipympl's canvas draw/resize/frame requests — are then serviced on a subshell thread concurrently with cell execution on the main thread. matplotlib is not thread-safe, so any live canvas racing a main-thread figure build corrupts shared state. This matches the ipykernel≥7 correlation reported here: with ipykernel < 7 (or commsOverSubshells: "disabled") the concurrency doesn't exist.

   The mathtext ValueError is only the first symptom. We serialized successive chokepoints with a shared process-global RLock and watched the failure move each time:

   1. Locking MathTextParser.parse (equivalent to PR monkeypatch _mathtext.Parser.parse() with a threading.Lock() #621's lock) removes the ValueError — and the race resurfaces as blank canvases and hard kernel crashes.
   2. Additionally locking FigureCanvasAgg.draw helps — and the race resurfaces as RuntimeError: ... did not call Figure.draw, because backend_bases._get_renderer temporarily monkeypatches figure.draw during print_figure(bbox_inches='tight'); a concurrent draw hits the raise-to-capture hook (silently blank frame), and two overlapping windows restore the real draw mid-print.
   3. Additionally locking FigureCanvasBase.print_figure helps again — but the frame path still can't be covered from outside: get_diff_image() reads renderer.buffer_rgba() and handle_resize mutates the figure on the comm thread, with no stable lockable API. On top of that, lock contention itself can starve the comm thread during long runs, so every canvas stays blank until execution finishes anyway.

   So a parse-only lock will reduce but not eliminate the breakage; a complete kernel-side fix would need ipympl's own message handlers (including frame production and resize) serialized against draws — or better, a way for ipympl's comms to opt out of subshells per comm target so they stay on the main shell.

   Verified workarounds: JupyterLab Settings Editor → commsOverSubshells: "disabled", then restart JupyterLab (it only applies to newly connected kernels) — fully stable afterwards, canvases fill in when the cell finishes (pre-4.4 semantics). Pinning ipykernel<7 works too.

   Environment: ipympl 0.10.0, matplotlib 3.11.0, ipykernel 7.3.0, JupyterLab 4.6.1, Python 3.14.

   (The above text was formulated by LLM. I read it multiple times and can confirm all parts that I understand, but I do not have a strong understanding of the code involved and cannot personally verify the suggested ipympl-side solution)
2. ianthomas23

   closed this as completedin #621on Jul 31, 2026