Debugger enters a second level of the same function

Hi,

I’m curious about why the debugger behaves as it does in the following case. I’m debugging the file model-zoo/vae_mnist.jl at master · FluxML/model-zoo · GitHub and I’m putting a breakpoint at row 94 (args = Args(; kws…)). The call stack looks as expected “Main → train”. However, when I step forward (i.e. execture “Args(; kws…)”), the call stack becomes “Main → train → #train#10”, where does this new level come from? Furthermore, it seems like I am stuck in this extra frame:
I have a second breakpoint at row 107 (loader = get_data(args.batch_size)) but I cannot reach that breakpoint. As soon as I hit row 100 (@info “Training on GPU”) the debugger enters file logging.jl#350 (*) and I am never (**) able to return to the breakpoint of row 107.

(*) This is probably the same issue as: VSCode debugger stops in a macro without breakpoint · Issue #1667 · julia-vscode/julia-vscode · GitHub

(**) Note that I’m not sure if “never” is because of super slow debugger or because of some weird reason such as breakpoint being set in frame “train” but since I’m stuck in frame “#train#10” it never actually hits it (I don’t really know how debuggers work).
I’m using Julia 1.6.1

Julia sometimes internally defines multiple “versions” of a function. When it comes to keyword functions there is first a function that “sorts” the keyword arguments and then passes the result on to a generated inner function that does the actual computation. From the debuggers point of view, these look like two separate function even though the user only wrote one function.

Keyword functions have in general been quite tricky to handle completely satisfactory in the debugger.

3 Likes