VS Code freezes during debug when trying to expand ciscoconfpase2 objects

[eudjinnl]

Type: Bug

First I faced this behavior in my own code. Then I tried to run code from manual for testing.
Example code was taken from ciscoconfparse2 manual https://www.pennington.net/py/ciscoconfparse2/tutorial_parent_child.html :

conf = """
policy-map QOS_1
 class GOLD
  priority percent 10
 class SILVER
  bandwidth 30
  random-detect
 class default
!
interface Ethernet0/0
 ip address 1.1.2.1 255.255.255.0
 no cdp enable
!
interface Serial1/0
 encapsulation ppp
 ip address 1.1.1.1 255.255.255.252
!
interface Serial1/1
 encapsulation ppp
 ip address 1.1.1.5 255.255.255.252
 service-policy output QOS_1
!
interface Serial1/2
 encapsulation hdlc
 ip address 1.1.1.9 255.255.255.252
!
class-map GOLD
 match access-group 102
class-map SILVER
 match protocol tcp"""
 
config = conf.split('\n')

from ciscoconfparse2 import CiscoConfParse
parse = CiscoConfParse(config)
serial_objs = parse.find_objects("^interface Serial")
print(serial_objs)

Steps to reproduce:

1. Start debuging the code.

2. execute line serial_objs = parse.find_objects("^interface Serial")

3. In Variables window try to expand object serial_obj
   serial_obj -> 0 -> all children -> 0

4. VS Code freezes

5. Afrer clicking red square button several times the xode execution cancelled and VS Code will unfreeze

It reproduses with all unnecessary plug-ins disabled
It reproduces in VS Code Insiders
There is no freeze in PyCharm wile expanding objects

Python 3.13.7
ciscoconfparse2==0.8.34

VS Code version: Code 1.104.1 (0f0d87fa9e96c856c5212fc86db137ac0d783365, 2025-09-17T23:36:24.973Z)
OS version: Windows_NT x64 10.0.19045
Modes:

System Info

Item	Value
CPUs	12th Gen Intel(R) Core(TM) i5-1240P (16 x 2112)
GPU Status	2d_canvas: enabled direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_graphite: disabled_off trees_in_viz: disabled_off video_decode: enabled video_encode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled webgpu: enabled webnn: disabled_off
Load (avg)	undefined
Memory (System)	15.73GB (2.27GB free)
Process Argv	--crash-reporter-id 5a772a63-00ab-4152-a0e3-b65436ccc523
Screen Reader	no
VM	0%

Extensions (12)

Extension	Author (truncated)	Version
vscode-django	bat	1.15.0
python-environment-manager	don	1.2.7
python-extension-pack	don	1.7.0
vsc-python-indent	Kev	1.21.0
debugpy	ms-	2025.10.0
python	ms-	2025.14.0
vscode-pylance	ms-	2025.8.1
vscode-python-envs	ms-	1.8.0
autodocstring	njp	0.6.1
intellicode-api-usage-examples	Vis	0.2.9
vscodeintellicode	Vis	1.3.2
jinja	who	0.0.8

A/B Experiments

vsliv368:30146709
binariesv615:30325510
nativeloc1:31344060
dwcopilot:31170013
dwoutputs:31242946
copilot_t_ci:31333650
e5gg6876:31282496
996jf627:31283433
pythonrdcb7:31342333
usemplatestapi:31297334
aj953862:31281341
nesew2to5:31336538
agentgpt4:31387437
nes-set-on:31351930
6abeh943:31336334
0927b901:31350571
ovs_t:31383295
0cj2b977:31352657
gaj49834:31362110
cloudbuttont:31379625
todos-1:31384886
multireplacestring:31387918
control_gpt5applypatchexclusively:31387916
3efgi100_wstrepl:31382709
trigger-command-fix:31379601
auto_model_enabled:31385282

[rchiodo]

This can happen for a number of reasons.

1. The object is very deep. Debugpy will parse the children of an item and call __repr__ on each. If there's a lot of them or the __repr__ on a child is slow (or the __repr__ causes infinite recursion), this could cause a hang.
2. The object's __repr__ is dependent on a function that requires either cross thread communication or having the GIL. When you're stopped at a breakpoint, the __repr__ can't get the GIL and would hang.

I think the problem is number 2.

I can see this in the log when I try this myself (during the variable expand).

0.02s - PyDB.do_wait_suspend
name: _recv_bytes (line: 323)
 file: C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.13_3.13.2544.0_x64__qbz5n2kfra8p0\Lib\multiprocessing\connection.py
 event: line
 arg: None
 step: CMD_STEP_INTO (original step: <Unknown: -1>)
 thread: <Thread(loguru-writer-1, started daemon 9232)>, thread id: pid_6460_id_2114146452816, id(thread): 2114146452816
0.00s -   Stack: C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.13_3.13.2544.0_x64__qbz5n2kfra8p0\Lib\multiprocessing\connection.py, _recv_bytes, 323
0.00s -   Stack: C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.13_3.13.2544.0_x64__qbz5n2kfra8p0\Lib\multiprocessing\connection.py, recv_bytes, 216
0.00s -   Stack: C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.13_3.13.2544.0_x64__qbz5n2kfra8p0\Lib\multiprocessing\queues.py, get, 385
0.00s -   Stack: c:\Users\rchiodo\source\testing\test_pylance\.venv313\Lib\site-packages\loguru\_handler.py, _queued_writer, 300
0.00s -   Stack: C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.13_3.13.2544.0_x64__qbz5n2kfra8p0\Lib\threading.py, run, 994
0.00s -   Stack: C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.13_3.13.2544.0_x64__qbz5n2kfra8p0\Lib\threading.py, _bootstrap_inner, 1043
0.00s -   Stack: C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.13_3.13.2544.0_x64__qbz5n2kfra8p0\Lib\threading.py, _bootstrap, 1014
0.00s -   Stack: c:\Users\rchiodo\.vscode\extensions\ms-python.debugpy-2025.14.1-win32-x64\bundled\libs\debugpy\_vendored\pydevd\_pydev_bundle\pydev_monkey.py, __call__, 1134
0.00s - Skipping per-thread thread suspend notification.
0.00s - Thread suspend mode: single notification

That's the other thread trying to handle a request from the (I'm guessing) the main thread during the variable expansion, but the other thread is suspended so it can't handle the request.

You can workaround this by explicitly printing out the __dict__ for those sub items. That doesn't cause a hang:

The __dict__ should have most of what would have been in that child var request.