Kernel Busy and cell status running ([*]) on Windows, after closing TK dialog a second time

[RRosio]

Description

In Windows, after opening and closing a TK dialog for the second time the kernel status remains busy. The cell status symbol [ ]: remains in running mode [*].
This issue is not present when running this code on an M1 Mac.

min_kernel_busy.mov

Reproduce

1). Run the code below.
2). A TK dialog will appear with a 'Test' button on it.
4). Close the dialog box.
5). The kernel is now idle as expected
6). Try the same thing again - now the kernel stays in busy state and does not go back to 'idle' state.

Expected behavior

Expect the kernel to update to 'idle' state and the cell status to update indicating it has finished running after closing the dialog box.

Context

• Operating System and version: Windows 11
• Browser and version: Microsoft Edge
• JupyterLab version: Version 4.1.4

Code to Reproduce

import tkinter as tk
from tkinter import *
from tkinter import ttk
from tkinter import filedialog as fd
import pandas as pd
import numpy as np
import matplotlib
import matplotlib.pyplot as plt
matplotlib.use('TkAgg')
from matplotlib.figure import Figure
from matplotlib.backends.backend_tkagg import (FigureCanvasTkAgg)
from matplotlib.backends.backend_tkagg import (NavigationToolbar2Tk)

def fileopen():
    print('Working on Busy Kernel issue')

root = Tk()
root.geometry("280x100")
root.title("Test_03/12/24")

mainframe = ttk.Frame(root, padding='0.25i')
mainframe.grid(column=0, row=0, sticky=(N, W, E, S))
root.columnconfigure(0, weight=1)
root.rowconfigure(0, weight=1)

# GUI Content
ttk.Button(mainframe, text ="Test", command = fileopen).grid(column=2, row=0, sticky=E)

for child in mainframe.winfo_children():
    child.grid_configure(padx=5, pady=5)

root.mainloop()

Command Line Output

No command line error message

Browser Output

No browser error message

[RRosio]

Posting here in case it is relevant:
When I run the attached code once, while the kernel status is idle and cell status is executed [1], shutting down the kernel gives the following traceback:

Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "C:\Users\rosio\miniconda3\envs\lab4\Lib\site-packages\ipykernel_launcher.py", line 18, in <module>
    app.launch_new_instance()
  File "C:\Users\rosio\miniconda3\envs\lab4\Lib\site-packages\traitlets\config\application.py", line 1075, in launch_instance
    app.start()
  File "C:\Users\rosio\miniconda3\envs\lab4\Lib\site-packages\ipykernel\kernelapp.py", line 739, in start
    self.io_loop.start()
  File "C:\Users\rosio\miniconda3\envs\lab4\Lib\site-packages\tornado\platform\asyncio.py", line 205, in start
    self.asyncio_loop.run_forever()
  File "C:\Users\rosio\miniconda3\envs\lab4\Lib\asyncio\base_events.py", line 639, in run_forever
    self._run_once()
  File "C:\Users\rosio\miniconda3\envs\lab4\Lib\asyncio\base_events.py", line 1970, in _run_once
    handle = self._ready.popleft()
             ^^^^^^^^^^^^^^^^^^^^^
IndexError: pop from an empty deque

• This IndexError is also reported in Failure to start jupyter lab --- IndexError: pop from an empty deque  #11934 although I have no issue continuing to use JupyterLab after shutting down the kernel associated with the TK dialog notebook/code.

[ccordoba12]

I can see in the code you posted that you are not enabling the Tk event loop before running your code, which could be the cause of this problem.

To do that you need to run this magic in another cell:

%gui tk

[sfweller84]

Hello Carlos,

Adding the above statement - %gui tk - doesn't help - kernel still remains in a busy state.
Can you try to repro the problem on your end?

Thank you!

[JasonWeill]

Does this happen in Jupyter Console as well? This may be a bug in ipykernel rather than JupyterLab if so.

[JasonWeill]

Still need feedback about whether this happens in Jupyter Console.

[RRosio]

I have verified that this issue is reproducible in Jupyter Console. As mentioned adding %gui tk to enable the Tk event loop did not change the outcome of running the cell a second time.

However, changing the order of the two statements matplotlib.use('TkAgg') and import matplotlib.pyplot as plt so that we set the Matplotlib backend before importing pyplot did allow the second run of that same code to terminate successfully without the same issue in the kernel status. @sfweller84, could you share if this change is helpful on your end?

[RRosio]

Closing this issue as it appears to not be an issue with JupyterLab itself but rather an issue with how matplotlib backends are set by a user.