justMyCode: false doesn't work

[MRogelio]

Type: Bug

• Create main.py that imports any library and use it
• Create a launch.json to launch your main.py and add the justMyCode: false
• Put a breaking point on the line where you use the external library
• Run the main.py through your launch.json
• Step into and you won't step into the external library

It worked in 1.89

VS Code version: Code 1.90.0 (89de5a8, 2024-06-04T19:34:48.028Z)
OS version: Darwin arm64 23.5.0
Modes:

System Info

Item	Value
CPUs	Apple M1 (8 x 2400)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: enabled_on 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 video_decode: enabled video_encode: enabled webgl: enabled webgl2: enabled webgpu: enabled
Load (avg)	4, 4, 4
Memory (System)	8.00GB (0.09GB free)
Process Argv	--crash-reporter-id f46645e3-cea5-4915-8607-ce5e20309859
Screen Reader	no
VM	0%

Extensions (38)

Extension	Author (truncated)	Version
better-comments	aar	3.0.2
rtf	ale	2.8.0
ruff	cha	2024.26.0
systemd-unit-file	coo	1.0.6
python-environment-manager	don	1.2.4
gitlens	eam	15.0.4
gc-excelviewer	Gra	4.2.59
vscode-vibrancy-continued	ill	1.1.34
svn-scm	joh	2.17.0
magit	kah	0.6.61
blockman	leo	1.7.7
rainbow-csv	mec	3.12.0
vscode-docker	ms-	1.29.1
vscode-language-pack-fr	MS-	1.89.2024050109
black-formatter	ms-	2024.2.0
debugpy	ms-	2024.6.0
isort	ms-	2023.10.1
python	ms-	2024.8.0
vscode-pylance	ms-	2024.5.1
remote-containers	ms-	0.369.0
remote-wsl	ms-	0.88.2
autodocstring	njp	0.6.1
indent-rainbow	ode	8.3.1
parallels-desktop	Par	1.1.16
python-dependencies-vscode	pat	0.0.21
vscode-yaml	red	1.14.0
gituserswitcher	rob	0.0.3
cod-sense	se2	1.0.2
markdown-preview-enhanced	shd	0.8.13
vscode-txgsc	shi	1.0.14
ruby-lsp	Sho	0.7.2
sonarlint-vscode	Son	4.6.0
even-better-toml	tam	0.19.2
chatgpt	tim	1.1.2
vscode-counter	uct	3.4.0
vscode-fold-level	vik	0.0.14
vscode-ruby	win	0.28.0
markdown-all-in-one	yzh	3.6.2

A/B Experiments

vsliv368:30146709
vspor879:30202332
vspor708:30202333
vspor363:30204092
vscod805:30301674
binariesv615:30325510
vsaa593cf:30376535
py29gd2263:31024239
c4g48928:30535728
azure-dev_surveyone:30548225
a9j8j154:30646983
962ge761:30959799
pythongtdpath:30769146
welcomedialog:30910333
pythonidxpt:30866567
pythonnoceb:30805159
asynctok:30898717
pythontestfixt:30902429
pythonregdiag2:30936856
pythonmypyd1:30879173
pythoncet0:30885854
h48ei257:31000450
pythontbext0:30879054
accentitlementst:30995554
dsvsc016:30899300
dsvsc017:30899301
dsvsc018:30899302
cppperfnew:31000557
dsvsc020:30976470
pythonait:31006305
jchc7451:31067544
chatpanelc:31048052
dsvsc021:30996838
0ee40948:31013168
pythoncenvpt:31062603
a69g1124:31058053
dvdeprecationcf:31061161
pythonprt:31056678
dwnewjupytercf:31046870
26j00206:31048877

[IllusionMH]

/extPython

Python debugger repo looks like better place to report this issue https://github.com/microsoft/vscode-python-debugger/issues

[vscodenpa]

It looks like this is caused by the Python extension. Please file the issue to the Python extension repository. Make sure to check their issue reporting template and provide them relevant information such as the extension version you're using. See also our issue reporting guidelines for more information.

Happy Coding!

[rchiodo]

I don't believe this is the fault of the python debugger. I can repro the problem 1.90, but not with 1.89, with both using the same version of the Python/Python Debugger extensions.

See this issue:
microsoft/debugpy#1596

[rchiodo]

For some reason VS code (in 1.90) isn't picking the topmost frame? Did 1.90 add some extra log around presentationHint for stack frames?

[roblourens]

#211855 @connor4312 ?

[connor4312]

Probably, though that was parity with #206801

I don't think this is a bug with debug, more probably something Python should tweak if this is not desirable. Summary is that previous VS Code only used deemphasize to indicate stack frames that should be elided, but this was not specified in DAP. DAP instead specifies subtle, and so we made a change to treat both subtle and deemphasize the same way.

The linked PR fixes one place I missed when making this migration back in March.

[roblourens]

So is there currently a way to mark a frame to be rendered in a certain way, but still allow stepping into it and revealing that frame? Or is that combo now not allowed?

[connor4312]

deemphasize/subtle don't control stepping, that up to the debuggee, but yes there's no control that allows the frame to be rendered a 'greyed out' but still go to its location when it is the top frame in the call stack.

Reviewing the code I realize we should probably make an adjustment: currently isFrameDeemphasized returns true if the frame or the source is deemphasized, but we should instead allow an explicit normal presentationHint on the stack frame to override the hint inherited from the source. Not sure what Python is doing or if that's sufficient 🙂

[roblourens]

Rich linked a log in microsoft/debugpy#1596 (comment), looks like they just set "presentationHint": "subtle" on the frame

[connor4312]

It was before my time, but I'm guessing the top of stack behavior was introduced to avoid ending up in random internals if e.g. the runtime was asked to pause on exceptions or just if the "pause" button is hit. But in the case where you're stepping, I think there's an expectation that you're taken to where you step to, and the behavior of not showing where you are can be confusing. Perhaps we always respect the top of the stack if the stop event's reason is step. I think that'd solve this case without protocol carve-outs. What do you think?

[roblourens]

I'm not sure

• Is it weird for this to be inconsistent between different stop reasons?
• Are you sure that behavior like this doesn't need to be called out in the spec somehow, since this seems important for knowing how to use those flags?

[connor4312]

Is it weird for this to be inconsistent between different stop reasons?

Maybe, I think in the step case intent is pretty clear and gives us an opportunity to do the right thing. I think the only odd case would be stepping out into a deemphasized frame, but stepping into a case where the top frame is deemphasized, and certainly stepping statements within a deemphasized frame, should respect the top frame.

Are you sure that behavior like this doesn't need to be called out in the spec somehow, since this seems important for knowing how to use those flags?

Not ruling that out, I would be good adding some wording to DAP indicating what UI implementors should/may do.

[roblourens]

Yeah. I think it's probably ok to do that

[connor4312]

Fyi the stable release with the fix went out yesterday

[lovettchris]

Fyi the stable release with the fix went out yesterday

it's working great, thanks!

[joon612]

Same issue here! When justMyCode is false, the breakpoint will not stop at any place!

(env) PS C:\Users\user> conda --version
conda 24.5.0
(env) PS C:\Users\user> python -V
Python 3.9.19
(env) PS C:\Users\user> code --version
1.91.1
f1e16e1e6214d7c44d078b1f0607b2388f29d729
x64

[connor4312]

Please take a recording of what you're doing with the full window, thanks. https://gifcap.dev/ is useful.

[joon612]

Please take a recording of what you're doing with the full window, thanks. https://gifcap.dev/ is useful.

Sorry the file is big, then I uploaded to a cloud drive: https://drive.google.com/file/d/1t6W6M6LIuy_91mIViyMuRVliB_0__wbk/view?usp=sharing

[connor4312]

The actual error is probably the one shown in the title of the Call Stack view that the file cannot be found, and therefore not displayed to you

[joon612]

The actual error is probably the one shown in the title of the Call Stack view that the file cannot be found, and therefore not displayed to you

I mean that when debugging after justMyCode is disabled, it doesn't automatically stop at the exception.

[connor4312]

Please open an issue on the Python repo for this, this looks unrelated

[joon612]

Please open an issue on the Python repo for this, this looks unrelated

OK, thanks for help.

[rchiodo]

I think the issue you opened (@joon612) is actually another symptom of the code change here in VS code.
You can see it in the GIF you provided. VS code is hitting the exception but hiding the callstack.

[rchiodo]

Oh it's unable to find a path? @connor4312 this would be on your side right?

[rchiodo]

No, that path doesn't actually exist. So the path returned by the debugger is incorrect. I'll reopen the issue on the debugger side.

[rchiodo]

Sorry that's not the path but the exception. The stack frames are still being hidden. So I do think this is another symptom of the original bug.

Here's the logs for when the problem occurs:

debugger_logs.zip

[rchiodo]

As you can see in the logs, it should be showing the stack frame starting at:

C:\\Users\\rchiodo\\AppData\\Local\\anaconda3\\envs\\Pesnet\\Lib\\ntpath.py

Which is where the exception is raised.

[connor4312]

Ah, yea, that's the behavior I mentioned in

I think in that case the current frame behavior is actually correct in showing users the line of their code that caused the exception to be thrown. They can then navigate into internals via the call stack view if they're interested in that.

Perhaps we should add a behavior such that the top frame is shown if there is no user code to navigate to