Debugging julia code

#1

What are good strategies for debugging Julia code? Can I debug the Julia code using gdb? I mainly want to see the variables at various points in the program.
Thank you.

1 Like
#2

println("var: ", var) :wink:

2 Likes
#3

Better @show variable.

8 Likes
#4

ASTInterpreter2 seems to work

#5

https://github.com/JuliaDebug/Debugger.jl is work-in-progress

3 Likes
#6

is there any option in which I can execute the code line by line? I have too many variables and printing/ showing all variables might not be an efficient way to debug.
Thank you.

#7

Line-by-line debugging requires some work on the compiler first. Check this thread for more infos:

1 Like
#8

Debugger.jl does precisely that:

julia> Debugger.@enter gcd(2,3)
In gcd(a, b) at intfuncs.jl:31
31  function gcd(a::T, b::T) where T<:Union{Int8,UInt8,Int16,UInt16,Int32,UInt32,Int64,UInt64,Int128,UInt128}
32      a == 0 && return abs(b)
33      b == 0 && return abs(a)

About to run: (==)(2, 0)
1|debug> n
In gcd(a, b) at intfuncs.jl:31
31  function gcd(a::T, b::T) where T<:Union{Int8,UInt8,Int16,UInt16,Int32,UInt32,Int64,UInt64,Int128,UInt128}
32      a == 0 && return abs(b)
33      b == 0 && return abs(a)
34      za = trailing_zeros(a)

About to run: (==)(3, 0)
1|julia> a+b
5

It’s not quite ready for a release yet, but I hope we’ll get there soon.

5 Likes
#9

It’s probably also worth mentioning Rebugger. I’m not sure how it compares to the in-progress Debugger.jl and would love to learn more!

1 Like
#10

ASTInterpreter2 seems to work

This seems to be a good package. It would be good to have a feature to print variable while debugging. “fr v” command lists variables, but not value of variables in some cases (especially matrices).
Thank you.

#11

You can just use ` to switch to a (kind of) julia repl and enter the variable there to get it displayed. Or index into or whatever.

Debugger.jl + JuliaInterpreter.jl will replace ASTInterpreter2.jl soon, with less bugs and significantly higher performance.

1 Like
#12

Awesome news! :slight_smile:

#13

Early adopters are welcome to play with it now, but keep in mind stuff may break. Hopefully within the next week or two we’ll have a major announcement and accompanying blog post.

The core work is happening in JuliaInterpreter; Debugger.jl, Rebugger.jl, and Juno will all be different “front ends.” If you’re interested exploring the new capabilities via Rebugger, try running with this branch of Revise and this branch of Rebugger.

In the meantime, if people want to help us get over the finish line, https://github.com/JuliaDebug/JuliaInterpreter.jl/issues/13 is looking for all the helpers we can get. The new debugger will support breakpoints and run all code in the interpreter, and for that to be a positive experience we have to be able to run any valid Julia code correctly. Julia’s own test suite is the best opportunity to find out how we’re doing. It’s starting to look pretty good (it wasn’t at the beginning :blush:) but there is no doubt that important fixes remain to be made.

12 Likes
#14

The only thing I’d really want from a debugger is the ability to inspect the stack when an error occurs, without having to rerun the computations. Is there any hope along those lines? Common Lisp could do it, and it had a very similar memory/execution model.

2 Likes
#15

Any plans to integrate Debugger into Juno?

#16

Yes, for sure. I plan to release a new Juno version with Debugger support at the same time the Debugger stack is released.

8 Likes
#17

The branch of Rebugger linked above should now be quite good at that, although (at least currently) it does require two passes, one to trigger the error and instrument the code, the second to capture the inputs.

But for an answer to what you’re precisely hoping for, it’s coming quite soon: https://github.com/JuliaDebug/JuliaInterpreter.jl/pull/81

2 Likes
#18

Doesn’t that PR require an explicit breakpoint(), thus I need run the code twice? Is there a way to automatically breakpoint on any exception?

#19

No, it doesn’t. See this test.

1 Like
#20

Ok, but… it implies running the whole thing inside of JuliaInterpreter.enter_call?

My scenario is: I do some development, then start some heavy computation. Five minutes later, there’s a MethodError. In Python or Common Lisp, I can directly step into the debugger and figure out what went wrong. I don’t think it’d be reasonable to run everything through JuliaInterpreter.jl, is it? It would have significant runtime cost.

That said, I need to try Rebugger again, thank you so much for sharing all of your efforts. I’m constantly amazed at how thorough you’ve been with Revise.jl!