Potjans_2014 example hangs in Jupyter notebook during simulation

[jhnnsnk]

Describe the bug
Simulation of NEST example Potjans_2014 hangs in Jupyter notebook

To Reproduce
Execute run_microcircuit.ipynb in the EBRAINS lab with the default kernel EBRAINS-24.04 (using NEST 3.7).
The simulation stops at [ 24% ] Model time: 117.8 ms.
There is no error message, it just hangs, but if the kernel is interrupted manually, this last time step is printed to screen.
I could also reproduce it with different EBRAINS kernels (other NEST versions) and locally with NEST 3.8 on my laptop.
However, running just python run_microcircuit.py from the command line works as expected; the simulation finishes in a few seconds.
It is not a problem with the .ipynb version of the script; it also hangs if I just copy the content of run_microcircuit.py into a Jupyter notebook cell.

Update: The simulation runs through in the Jupyter notebook if times are not printed, nest.SetKernelStatus({"print_time": False}). Other examples, for instance, One neuron, finish as expected in the notebook if nest.SetKernelStatus({"print_time": True}).

Credit: This bug was first reported by @Sir-Bip-Bop who also discovered the relationship with "print_time".

[clinssen]

I'm experiencing similar issues and suspect that there was an update in Jupyter that broke this. If I recall right, I was seeing this in both Jupyter-notebook and Jupyter-lab. I've seen this on very small networks (with just a handful of neurons/connections). It occurs both for multi-threaded and single-threaded simulations.

Does it work for you to interrupt the kernel (press the stop button) and then re-run the affected cell?

Does it run through okay when you use ipython rather than Jupyter (when you invoke ipython3 run_microcircuit.ipynb)?

The trick with not printing simulation progress seems to resolve the issue for me as well, however, nothing seems suspect in the associated print code at first sight.

[Sir-Bip-Bop]

Running the cell again and running through ipython both work okay. I've encountered this issue on the example code regardless of the scale factor.

[clinssen]

@terhorstd mentioned this could be due to Jupyter capturing stdout/stderr, and its IO buffers getting filled up too fast.

See jupyterlab/jupyterlab#12845