Debugger no longer hits breakpoints in VSC?

[joa-quim]

When now do @run ... no breakpoints are hit. That means no debugger at all-
Only me?

[joa-quim]

Ping

[karei]

Julia debugging is extremely slow

Well, you can select which libraries shall be compiled. If you are not debugging the CSV library, just compile it: Debugging · Julia in VS Code You can also try https://plugins.jetbrains.com/plugin/29356-flexible-julia, which is a commercial offering, so you need to pay for it unless you work at a university. On the other hand, if you have a bug report or feature request they address that very fast.

Julia debugging is extremely slow

I would recommend just using Infiltrator.jl and putting an @infiltrate everwhere you want to inspect variables, and remove all of them when you are done.

[joa-quim]

And what does pretend to mean?

[pfitzseb]

Please provide at least a few details when asking for help, like version of the extension and julia, what code you’re trying to debug, your compiled modules config etc.

[joa-quim]

I think this happened after the before latest VSC update. I used this for years. Should be latest extension version on Windows, Julia 1.10. Nothing works now. I put the breakpoints, run @run ... and the code never stops at the breakpoints neither on lines when it errors.

[DNF]

Found this thread as I was searching for debugger issues.

So this has been my experience more or less over the past year. Developing on VS Code under windows, with julia on more-or-less latest or nearly latest version, and pre-release version of the vs code plugin (I should probably have tried the release version instead).

The debugger crashes (exits) all the time. If I use @enter, it will start, but soon grind to a halt. Breakpoints are hit some times and some times not. For the past weeks or months, @run does not work. It just appears to start, then finishes without hitting any breakpoints. It’s hard to know how many times to hit the step buttons. Hitting it once or twice on a line does nothing, there’s just a spinner saying “Julia: evaluating”. Hitting it a third or fourth time it suddenly responds and steps. So you hit the stepping buttons randomly until you suddenly step too far.

Most of the time I use the debugger it ends up crashing my julia session, which is a bit tiresome since startup is slow for my project. But if I try to use the debug console, not matter how trivial the expression, Julia always, without exception “terminates with exit code 1”.

I use compiled code for everything except my package.

In general I have given up the debugger, but perhaps this is a Windows problem? Occasionally I consider moving to Linux.

[pfitzseb]

This is probably due to the default settings having changed in

fix: improve default debugger compiled item list (#4038)

Feel free to use the original list locally for now.

@DNF

It just appears to start, then finishes without hitting any breakpoints

This happens when the wrong functions/modules are set to compiled mode. It’s not easy to find this set though, but hopefully feat: add scripts to auto-generate default interpreted items by pfitzseb · Pull Request #4043 · julia-vscode/julia-vscode · GitHub will help once it’s in.

@DNF

It’s hard to know how many times to hit the step buttons. Hitting it once or twice on a line does nothing, there’s just a spinner saying “Julia: evaluating”. Hitting it a third or fourth time it suddenly responds and steps. So you hit the stepping buttons randomly until you suddenly step too far.

Yeah, that is pretty annoying. There are issues with kwrappers not being transparently stepped through, which may explain some of this. The other issue is that VS Code doesn’t provide a UI to show which expression will be run next, like Juno did back in the good old days:

In theory “Run to Cursor” and “Step into target” should help a little, but I think both of those broke at some point in the past (which isn’t surprising – much of the debugger is very closely tied to Julia internals).

@DNF

I use compiled code for everything except my package.

Note that you also need to set higher order functions as interpreted if you want breakpoints to work in any of their callees.

@DNF

In general I have given up the debugger, but perhaps this is a Windows problem? Occasionally I consider moving to Linux.

It’s probably equally bad on Linux, but tbf I don’t test many things on Windows, so there may be OS specific bugs.

Edit: Oh, you can also set ENV["JULIA_DEBUG"] = "DebugAdapter,DebugEngines" for a lot of potentially helpful debug output (it’ll certainly tell you when your “step over” did something)

[DNF]

Thanks for your reply. I will try some of these things.

@pfitzseb

The other issue is that VS Code doesn’t provide a UI to show which expression will be run next, like Juno did back in the good old days:

Are you sure about this? I use VS Code for developing C++ (this is on a different laptop I don’t have right now), and there are definitely some indicators showing which expression is ‘up next’.

[pfitzseb]

@DNF

Are you sure about this? I use VS Code for developing C++ (this is on a different laptop I don’t have right now), and there are definitely some indicators showing which expression is ‘up next’.

No, not at all sure Do you have a screenshot/some more info on this?

[DNF]

I will take a look when I have other laptop on hand!

[joa-quim]

Tried with an older Julia extension version. Tried Antigravity. Nothing, no debugger at all.

[franckgaga]

@pfitzseb

This is probably due to the default settings having changed in

fix: improve default debugger compiled item list by pfitzseb · Pull Request #4038 · julia-vscode/julia-vscode · GitHub

Feel free to use the original list locally for now.

I had the same problem, I applied a list similar to the original one and the debugger now work as expected, thanks!

When I say as expected I mean: I have project environment in which I dev my package ModelPredictiveControl.jl. I expect that breakpoints inside the code of MPC.jl won’t be ignored, since the package is deved. Out of curiosity, how the new default ALL_MODULES_EXCEPT_MAIN is better than the old list, other than for performances ? It seems that a debugger that is slow but stop in the deved package is way more intuitive and just a better default, no ?

[joa-quim]

What is the old or original list?

[franckgaga]

The list of modules and functions here. The - char means “keep this function interpreted in this module”. You need to add the elements of this list in the “Compiled” section of VS Code. Here is a screenshot with my current settings:

[joa-quim]

Merci,

I’ve tried that as well. With all compiled or interpreted and nothing. No debugger.
BTW, mt VSCode version is 1.111

[Maucejo]

Hi all, I am following this thread because I don’t understand how to debug my code since the last release of the VSCode extension. I usually use @enterand @run to start a debugging session. However, since the change of the default debugger settings, I can’t debug my code, I am facing the same issues as @joa-quim. Even if everything is interpreted, the debugger doesn’t stop at breakpoints.

My version of VSCode is 1.111.0 and the version of the Julia extension is 1.197.1.

Despite this slight grief, thank you for all the hard work you put in the extension.

[joa-quim]

Sorry, didn’t report back. Among reverting to an older VSC (but I’m now back to 1.111.0), going back to older Julia extension versions (I’m now at 1.189.2), moving from Julia 1.10 to 1.12 (on VSC only) something on this made it work de debugger again. Not so helpful but can’t be more specific.