Stacktrace in Juno is confusing - did I miss something?

juno

#1

Transferring the question to the “Usage” tag to hopefully get an answer. Thanks!!

I’m running JuliaPro 0.6.2 and the Juno that comes with it (Atom 1.23.3 ia32, julia-client 0.6.9). The Console Style setting is REPL-based. My OS is Windows 10 64-bit Enterprise.

First, thanks a lot for the new light-weight REPL in Juno - I love it. I had switched to VS Code earlier because I couldn’t bear the slowness of the legacy Julia console in Juno, but now I’m back as the new REPL console is much faster (at the same level as VS Code or a simple Julia console), and Juno’s debug interface using ASTInterpreter2 is fabulous - VS Code lacks this feature so far.

However, Juno’s Stacktrace is confusing to me. If an error happens in a function or a module, the Stacktrace does not show the location in the user’s code (file and line number) where the error actually occurred. The same code in a simple Julia console or VS Code will show a different Stacktrace which contains the aforementioned information.

Since this is such a common feature people use, is there a setting or something to make Juno Stacktrace useful that I don’t know of?

Here’s an example script:

function main()
    println("This function contains an error in line 3.");
    printlm("This line contains the error.");
end

main();

If you run this in Juno by clicking the Run File button, the following Stacktrace is produced:

This function contains an error in line 3.
ERROR: LoadError: UndefVarError: printlm not defined
Stacktrace:
 [1] (::Atom.##110#114{String,String})() at C:\JuliaPro\pkgs-0.6.2.2\v0.6\Atom\src\eval.jl:104
 [2] withpath(::Atom.##110#114{String,String}, ::String) at C:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\JuliaPro\pkgs-0.6.2.2\v0.6\CodeTools\src\utils.jl:30
 [3] withpath(::Function, ::String) at C:\JuliaPro\pkgs-0.6.2.2\v0.6\Atom\src\eval.jl:38
 [4] hideprompt(::Atom.##109#113{String,String}) at C:\JuliaPro\pkgs-0.6.2.2\v0.6\Atom\src\repl.jl:65
 [5] macro expansion at C:\JuliaPro\pkgs-0.6.2.2\v0.6\Atom\src\eval.jl:99 [inlined]
 [6] (::Atom.##108#112{Dict{String,Any}})() at .\task.jl:80
while loading C:\depot\Projects\NOON\Documents\Arch\OpticalSystem_Architecture\ILS_Gen4\HSL_EDFA\SupportingDocuments\Ex
ampleWithError.jl, in expression starting on line 6

The Stacktrace only showed there is a problem at line 6, which is the line calling main(). There is no information regarding line 3 inside the function main() at all. The user has to search for the word “printlm” in the source code to find out where the error is. If there are multiple places “printlm” shows up (e.g. in other functions), it takes time to figure out exactly which one caused the current error.

But if you run this script in a simple Julia console or VS Code using “include”, a different Stacktrace is produced:

julia> include("ExampleWithError.jl")
This function contains an error in line 3.
ERROR: LoadError: UndefVarError: printlm not defined
Stacktrace:
 [1] main() at C:\depot\Projects\NOON\Documents\Arch\OpticalSystem_Architecture\ILS_Gen4\HSL_EDFA\SupportingDocuments\ExampleWithError.jl:3
 [2] include_from_node1(::String) at .\loading.jl:576
 [3] include(::String) at .\sysimg.jl:14
while loading C:\depot\Projects\NOON\Documents\Arch\OpticalSystem_Architecture\ILS_Gen4\HSL_EDFA\SupportingDocuments\ExampleWithError.jl, in expression starting on line 6

Item [3] of the Stacktrace points to the line calling main(), but item [1] clearly showed line 3 in ExampleWithError.jl is where the error occurred.

We can add a twist to this example and get even more interesting result. If we use @time to measure how much time and memory it takes to run function main():

function main()
    println("This function contains an error in line 3.");
    printlm("This line contains the error.");
end

@time main();

Running the file in Juno produces:

This function contains an error in line 3.
ERROR: LoadError: UndefVarError: printlm not defined
Stacktrace:
 [1] (::Atom.##110#114{String,String})() at C:\JuliaPro\pkgs-0.6.2.2\v0.6\Atom\src\eval.jl:104
 [2] withpath(::Atom.##110#114{String,String}, ::String) at C:\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\JuliaPro\pkgs-0.6.2.2\v0.6\CodeTools\src\utils.jl:30
 [3] withpath(::Function, ::String) at C:\JuliaPro\pkgs-0.6.2.2\v0.6\Atom\src\eval.jl:38
 [4] hideprompt(::Atom.##109#113{String,String}) at C:\JuliaPro\pkgs-0.6.2.2\v0.6\Atom\src\repl.jl:65
 [5] macro expansion at C:\JuliaPro\pkgs-0.6.2.2\v0.6\Atom\src\eval.jl:99 [inlined]
 [6] (::Atom.##108#112{Dict{String,Any}})() at .\task.jl:80
while loading C:\depot\Projects\NOON\Documents\Arch\OpticalSystem_Architecture\ILS_Gen4\HSL_EDFA\SupportingDocuments\Ex
ampleWithError.jl, in expression starting on line 237

Now this is interesting as the whole file ExampleWithError.jl contains only 6 lines. This mysterious line 237 seems to be something internal to the macro @time?

Running it in a simple Julia console or VS Code produces:

julia> include("ExampleWithError.jl")
This function contains an error in line 3.
ERROR: LoadError: UndefVarError: printlm not defined
Stacktrace:
 [1] main() at C:\depot\Projects\NOON\Documents\Arch\OpticalSystem_Architecture\ILS_Gen4\HSL_EDFA\SupportingDocuments\ExampleWithError.jl:3
 [2] include_from_node1(::String) at .\loading.jl:576
 [3] include(::String) at .\sysimg.jl:14
while loading C:\depot\Projects\NOON\Documents\Arch\OpticalSystem_Architecture\ILS_Gen4\HSL_EDFA\SupportingDocuments\ExampleWithError.jl, in expression starting on line 237

The mysterious line 237 shows up again. But at least here we have item [1] which points out where the real problem is, so it’s acceptable.

The newly improved Juno with ASTInterpreter2 debugging feature allows me to work within Juno most of the time, with the exception that I have to go repeatedly to a simple Julia console or VS Code when a Stacktrace does not give me information on the location of an error. Can someone help me to get around this problem? Many thanks!!!


#2

This is fixed on Juno master (and therefore the next version), afaict:


#3

Wonderful! Thanks for letting me know!