Sorry for the noobish question (borderline between Tooling and General usage). I needed to debug a piece of Julia code yesterday, so I checked online what was the official debugger. I was surprised to find there isn’t one; or better, there are different packages (third-party-ish) used to accomplished debugging. Since the documentation I found is a bit dated, and IIUC debugging is a topic actively developed in Julia, I wanted to ask you what is the updated situation, as of late 2022.
- what is the standard way to debug in Julia? What are the differences between the various packages?
For what I understood:
Debugger.jl is the most complete and “standard-interface” debugger. It provides usual commands (a-la-GDB), suffers from poor performance, and it’s the one used by VSCode and Juno. This is the “official” Julia debugger
Infiltrate.jl is used to quickly inspect the state of the program at a given point, but can do only that (no stepping, evaluation, watching, breakpoints)
Rebugger.jl is basically dead
… how many did I manage to get wrong?
- Also, naive question, if Julia is using LLVM, can’t LLDB be used to debug?
You are pretty much correct. And yes, you can use gdb or lldb or rr to debug julia as well, and they play reasonably well with JIT code, though it’s that easy to parse what’s going on from these debuggers if you don’t know what’s going.
Using VSCode, Debugger.jl is reasonably fast in my experience. The trick is to make sure that packages you don’t plan to need to step into are running in compiled mode. Often this just means that Base should be run in compiled mode (which is true by default). In practice just having base in compiled mode seems to be sufficiently fast. (In the past Base was not run in compiled mode by default, and if you use Debugger.jl outside of VScode I think this is still the case, but haven’t checked recently). But it can also be good to mark large well used and supported packed as being in compiled mode.
In spite of that, I often find myself just using Infiltrator since it is easy to use and suffices for many purposes, especially with @exfiltrate. This is a better interface I’d you want to mess around a lot with things in the REPL.
Many times I will often just use @debug or @show, that can work better for debugging, e.g. when evaluating an algorithms data flow.
Thanks to both!
To @gbaraldi : sorry, did you mean that LLDB output is not easy to parse?
To @haberdashPI thanks for your suggestions. The documentation of
Debugger unfortunately is not very clear: can you tell me how can I turn on compiled mode only for specific modules?
Yeah . It’s not anything out of the ordinary, but knowing a bit of julia internals will go a long way if you want to use it. I wouldn’t use it for debugging normal julia code though.
In VSCode, you need to do F5 Start Debugging, then in the bottom of the Run and Debug panel, a subpanel called “Julia: Compiled Code” appears.
In the latest version, it seems all code is compiled by default. You need to explicitly set modules you want to step through as interpreted. Click + button in the Julia subpanel, and prefix your module name with
There does seem to lack a central source for the most common way to debug. The tools are changing all the time.
Thanks! But actually I am not currently using VSCode. When using another editor/CLI, when you say “explicitly set the modules to be interpreted” are you referring to the
@enter macro, or to something else?