Call stack is very confused on error

[KristofferC]

I have lately been getting very confusing call stacks in the error messages that make no sense from how I know my calls are being made.

For example:

ERROR: BoundsError: attempt to access 28-element Array{Float64,1} at index [[4,6,13,15,22,24,31,33]]
 in throw_boundserror(::Array{Float64,1}, ::Tuple{Array{Int64,1}}) at ./abstractarray.jl:132
 in _internal_checkbounds at ./multidimensional.jl:219 [inlined]
 in checkbounds at ./multidimensional.jl:215 [inlined]
 in _getindex at ./multidimensional.jl:271 [inlined]
 in getindex at ./abstractarray.jl:425 [inlined]
 in zero at /home/kristoffer/.julia/v0.5/ContMechTensors/src/ContMechTensors.jl:72 [inlined]
 in intf(...)  at /home/kristoffer/Dropbox/julia/ViscoCrystalPlast/src/dual/intf_dual.jl:50
 in zero at /home/kristoffer/.julia/v0.5/ContMechTensors/src/ContMechTensors.jl:105 [inlined]
 in assemble!(...)  at /home/kristoffer/Dropbox/julia/ViscoCrystalPlast/src/solve_problem.jl:85
 in solve_problem(..) at /home/kristoffer/Dropbox/julia/ViscoCrystalPlast/src/solve_problem.jl:44
 in startit(::JuAFEM.Dim{3}) at /home/kristoffer/Dropbox/julia/ViscoCrystalPlast/experiments/compute_gradient_energy_dual.jl:64
 in eval(::Module, ::Any) at ./boot.jl:225
 in macro expansion at ./REPL.jl:92 [inlined]
 in (::Base.REPL.##1#2{Base.REPL.REPLBackend})() at ./event.jl:46

There are many problems with this call stack:

• It suggests that the function zero in ContMechTensors.jl calls intf which is not true. assemble! calls intf directly.
• It says that the error is at /intf_dual.jl:50 which runs a command fill!(fe_u, zero(Vec{dim, T})) so the call above at zero makes sense, if that is where the error actually happened, but it isn't.
• The error is actually at line 75 where I have a[ξ⟂_node_dofs] and ξ⟂_node_dofs are the indices which access the array OOB. However, at this line there is no calls to zero at all so how did those get into the call stack?

This is from my research code so it is quite messy to get running so I don't have a MWE right now. I could try to check if it was introduced in #16335 if that would help?

[KristofferC]

The error message seems to be "stuck" at line 50 even when I have other errors happening at other places in the function.

[vtjnash]

Does it work with ./julia -O0?

[KristofferC]

No, error message is identical with -O0

[quinnj]

Not sure if this is related, but I've been seeing a regression in stack traces when loading modules

Current master:

julia> reload("FlatBuffers")
ERROR: LoadError: syntax: missing comma or ) in argument list
 in include_from_node1(::String) at ./loading.jl:426
 in eval(::Module, ::Any) at ./boot.jl:225
 in require(::Symbol) at ./loading.jl:357
 in reload(::String) at ./loading.jl:308
 in eval(::Module, ::Any) at ./boot.jl:225
 in macro expansion at ./REPL.jl:92 [inlined]
 in (::Base.REPL.##1#2{Base.REPL.REPLBackend})() at ./event.jl:46
while loading /Users/jacobquinn/.julia/v0.5/FlatBuffers/src/FlatBuffers.jl, in expression starting on line 1

Julia 0.4.1

julia> include("/Users/jacobquinn/.julia/v0.5/FlatBuffers/src/FlatBuffers.jl")
ERROR: LoadError: syntax: missing comma or ) in argument list
 in include at /Users/jacobquinn/julia4/lib/julia/sys.dylib
 in include_from_node1 at /Users/jacobquinn/julia4/lib/julia/sys.dylib
while loading /Users/jacobquinn/.julia/v0.5/FlatBuffers/src/FlatBuffers.jl, in expression starting on line 141

[KristofferC]

Since I don't have a good repo for this right now, I will close this and reopen if this happens again.

[KristofferC]

After a colleague also reported getting strange backtrace errros with the ContMechTensors package I looked into it a bit more and found this MWE:

Pkg.clone("https://github.com/KristofferC/ContMechTensors.jl")
using ContMechTensors

a = zero(Vec{3, Float64})

function f(a)
    dot(a,a)
    print("hello...")
    a[5] # Will error here with BoundsError
end

The stacktrace is

ERROR: BoundsError: attempt to access 3-element ContMechTensors.Tensor{1,3,Float64,3} at index [5]
 in throw_boundserror(::ContMechTensors.Tensor{1,3,Float64,3}, ::Tuple{Int64}) at ./abstractarray.jl:272
 in checkbounds at ./abstractarray.jl:201 [inlined]
 in getindex at /home/kristoffer/.julia/v0.5/ContMechTensors/src/indexing.jl:33 [inlined]
 in dot at /home/kristoffer/.julia/v0.5/ContMechTensors/src/tensor_ops.jl:4 [inlined]
 in f(::ContMechTensors.Tensor{1,3,Float64,3}) at ./REPL[3]:2

The call to dot here is wrong since that is executed successfully on the first line so it should not even exist in the backtrace.

[KristofferC]

Note that it is also reporting the error at ./REPL[3]:2 which is at the call to dot but this is not where the error actually happens.

[KristofferC]

Running stacktrace after the dot command still shows that we it thinks we are inside the dot call so it seems that the frame is not properly getting "popped" of the stack after returning.

[yuyichao]

What's code_warntype of different versions of f?

[KristofferC]

You mean on f on different versions of Julia or @code_warntype on other functions that give similar erroneous backtrace?

[yuyichao]

For any f and julia version that gives bad backtrace

[KristofferC]

https://gist.github.com/KristofferC/964c4920d170b517569306d6107ad2ed

One with the above example and one when using zero instead. Same problem.

[KristofferC]

Doing something like:

function f_dot(a)
       dot(a,a)
       dot(a,a)
       dot(a,a)
       dot(a,a)    
       a[5] # Will error here with BoundsError
end

gives

ERROR: BoundsError: attempt to access 3-element ContMechTensors.Tensor{1,3,Float64,3} at index [5]
 in throw_boundserror at ./abstractarray.jl:272
 in checkbounds at ./abstractarray.jl:201 [inlined]
 in getindex at /home/kristoffer/.julia/v0.5/ContMechTensors/src/indexing.jl:33 [inlined]
 in dot at /home/kristoffer/.julia/v0.5/ContMechTensors/src/tensor_ops.jl:7 [inlined]
 in dot at /home/kristoffer/.julia/v0.5/ContMechTensors/src/tensor_ops.jl:5 [inlined]
 in dot at /home/kristoffer/.julia/v0.5/ContMechTensors/src/tensor_ops.jl:4 [inlined]
 in dot at /home/kristoffer/.julia/v0.5/ContMechTensors/src/tensor_ops.jl:3 [inlined]
 in f_dot at ./REPL[50]:2

Corresponding @code_warntype: https://gist.github.com/KristofferC/b3d504544c5ff4685e8ef54501ca2857

[KristofferC]

The line numbers on the inlined functions seem to be weird as well since they call the same function but have different line numbers.

[yuyichao]

Can you check if this patch fixes it?

diff --git a/base/inference.jl b/base/inference.jl
index 79edb33..28ae824 100644
--- a/base/inference.jl
+++ b/base/inference.jl
@@ -2045,7 +2045,7 @@ function expr_cannot_delete(ex::Expr)
     # `Expr(:inbounds)` and `Expr(:boundscheck)`. However, it is still possible
     # to have these embeded in other expressions (e.g. `return @inbounds ...`)
     # so we check recursively if there's a matching expression
-    (ex.head === :inbounds || ex.head === :boundscheck) && return true
+    (ex.head === :inbounds || ex.head === :boundscheck || ex.head === :meta) && return true
     for arg in ex.args
         isa(arg, Expr) && expr_cannot_delete(arg::Expr) && return true
     end

[KristofferC]

It does not from what I can see.

[yuyichao]

OK, I think I find a fix, will write a test and submit a PR.