Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Render Variable in Debugger fails with infinite loader #16973

Open
Enum0 opened this issue Nov 19, 2024 · 2 comments
Open

Render Variable in Debugger fails with infinite loader #16973

Enum0 opened this issue Nov 19, 2024 · 2 comments
Labels
bug pkg:debugger

Comments

@Enum0
Copy link

Enum0 commented Nov 19, 2024

Description

Bebugger fails rendering variables for 'self' objects. Instead of variable value it displays an infinite loader.

As a workaround I use 'copy to clipboard' option, which is a bit inconvinient.

I found the similar issue #11009, which was resolved in 2022. But looks like it is here again.

image

Reproduce

  1. Create a class with private attribute and some method. Create an instance of this class.
  2. Turn on the debug mode.
  3. Add a new line and mark it as a breakpoint: call the method of this instance.
  4. Go to the variable inspector, right-click on this variable in the self object. Click 'render variable'.
  5. It opens the new tab with infinite loader instead of variable value.

Expected behavior

The variable is rendered.

Context

  • Operating System and version: Windows 11 23H2
  • Browser and version: Edge 131.0.2903.51
  • JupyterLab version: 4.3.0
Troubleshoot Output 
Paste the output from running `jupyter troubleshoot` from the command line here.
You may want to sanitize the paths in the output.
Command Line Output 
Paste the output from your command line running `jupyter lab` here, use `--debug` if possible.
Browser Output 
Paste the output from your browser Javascript console here, if applicable.
@Enum0 Enum0 added the bug label Nov 19, 2024
@jupyterlab-probot jupyterlab-probot bot added the status:Needs Triage Applied to new issues that need triage label Nov 19, 2024
@3coins 3coins added pkg:debugger and removed status:Needs Triage Applied to new issues that need triage labels Nov 19, 2024
@3coins
Copy link
Contributor

3coins commented Nov 19, 2024

I am able to reproduce this issue in JupyterLab v4.3.1, and this seems to happen with any variable of the class not just private ones. Here is the stack trace from the kernel error.

[IPKernelApp] ERROR | Exception in control handler:
Traceback (most recent call last):
  File "/Users/pijain/miniforge3/envs/jupyter-ai/lib/python3.11/site-packages/ipykernel/kernelbase.py", line 362, in process_control
    await result
  File "/Users/pijain/miniforge3/envs/jupyter-ai/lib/python3.11/site-packages/ipykernel/kernelbase.py", line 1039, in debug_request
    reply_content = await reply_content
                    ^^^^^^^^^^^^^^^^^^^
  File "/Users/pijain/miniforge3/envs/jupyter-ai/lib/python3.11/site-packages/ipykernel/ipkernel.py", line 533, in do_debug_request
    return await self.debugger.process_request(msg)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/pijain/miniforge3/envs/jupyter-ai/lib/python3.11/site-packages/ipykernel/debugger.py", line 731, in process_request
    reply = await handler(message)
            ^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/pijain/miniforge3/envs/jupyter-ai/lib/python3.11/site-packages/ipykernel/debugger.py", line 664, in richInspectVariables
    repr_data, repr_metadata = eval(reply["body"]["result"], {}, {})
    ^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: cannot unpack non-iterable NameError object

@RRosio RRosio mentioned this issue Nov 19, 2024
Open
@krassowski
Copy link
Member

@3coins it looks like this issue should be reported and addressed upstream in ipykernel, do I see it right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug pkg:debugger
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@3coins @krassowski @Enum0