Tips for debugging in Julia - VS Code while using large packages?

Tooling VS Code
1

I have tried the debugger in VS Code with some simple scripts and it seems to work just fine. However, when I try to debug some production code that uses “large” packages (DifferentialEquations, Plots and a few more), it seems like the debugger hangs. I suspect that in reality it is just VERY busy interpreting (as opposed to compiling) these large libraries, but I don’t know enough of the inner workings to be certain.

I am trying to find a subtle bug in a set of differential equations for a reactor model that has very non-trivial (as in several pages of code) kinetics, so a debugger would be a blessing here.

If anyone has some experience in using the debugger in code that uses these (or similar) libraries and cares to share some tips and best practices, I would love to hear from you.

2

If you don’t need breakpoints, use the Compiled Mode toggle in the breakpoints section:
image

If you do, consider putting them before expensive operations and then stepping to the target location.

Now, if that’s also not possible, consider giving Infiltrator.jl a go, which drops you into a REPL session at your breakpoint but doesn’t allow any further stepping.

2 Likes
3

Naive question but what’s the typical debugging workflow with the debugger but without breakpoints? (I can imagine lots of ways to debug in general, but I must be missing something obvious because the obvious use of a debugger seems to be set breakpoint => run to breakpoint => step through code in debugger.)

4

Skip the first two steps? :slight_smile:
Mostly useful only when you can start debugging close to where you want (or just extract the part that you’re interested in). But yeah, obviously that’s a big limitation and hopefully we’ll get some big improvements in the future (e.g. combining Infiltrator.jl and Debugger.jl).

2 Likes
5

If a breakpoint is made after a time consuming segment of code, it is much slower than stepping through to that point?

So it is faster just to do a @enter and move down to your desired point? (than using break points)

6

So the only distinction in runtime is whether you’re running in compiled mode or not. If you are, breakpoints that are not in the current local scope won’t work.

7

Can you switch between compiled mode and not inside of one debugging session? (The compiled mode check box seems to be checkable, but it’s not obvious when the results take effect: immediately? Next Juno.@enter? On Julia restart?

In compiled mode, does stepping to a selected line work, and would that function much like a breakpoint? (Albeit not a conditional breakpoint)?

8

Yeah, that takes effect immediately.

In that case a breakpoint should actually work fine, provided you don’t pass any function boundaries. But otherwise just hit “Step Over” a few times and you should be good to go.

1 Like
9

After mucking about for half an hour or so I’ve yet to find the so called “breakpoints section:”. Has that been removed here in Nov. 2022?

So far the debugger has been completely unusable. I’ve yet to reach a breakpoint anywhere in my code. It’s just too slow I think.

10

You should consider adding your slow packages to the compiled mode, one’s that you don’t need to debug. There’s a section for the compiled modules and when you add a package, but a “.” after to specify all bits in the module.

So for CUDA, when adding write CUDA.. I would suggest adding all the packages that aren’t your own code, like Plots, CUDA etc.

Also don’t debug from scratch, try to use the REPL workflow and @enter.

Edit: The breakpoints section is under the debugging tab in VS code, and just lists the breakpoints you have set.

11

Thanks I finally found it and I have been adding everything I could think of into the compiled code section. Unfortunately the debugger is still unusable for me. Besides being very slow it appears to throw an exception in various modules. Currently it get’s stuck in JLD2, but I’ve been unable to create a small example file to isolate this problem.

The stand alone Debugger module still works fortunately. This is a definite downgrade from Juno functionality, which also is much slower than the Debugger module, but actually usable, unlike the current state of the VSCode debugger.