Error in interaction with JuMP

[baggepinnen]

I get an error while using TraceCalls together with JuMP. Without @trace, the Eception trace looks like this

ERROR: invalid index 1
Stacktrace:
 [1] ProximalOperators.SlicedSeparableSum(::Array{ProximalOperators.ProximableFunction,1}, ::Array{Tuple{AbstractArray{Int64,1}},1}) at /home/fredrikb/.julia/v0.6/ProximalOperators/src/calculus/slicedSeparableSum.jl:36
 [2] loadproblem!(::FirstOrderSolvers.FOSMathProgModel, ::Array{Float64,1}, ::SparseMatrixCSC{Float64,Int64}, ::Array{Float64,1}, ::Array{Any,1}, ::Array{Any,1}) at /home/fredrikb/.julia/v0.6/FirstOrderSolvers/src/FOSSolverInterface.jl:44
 [3] #build#1336(::Bool, ::Bool, ::JuMP.ProblemTraits, ::Function, ::JuMP.Model) at /home/fredrikb/.julia/v0.6/JuMP/src/solvers.jl:324
 [4] (::JuMP.#kw##build)(::Array{Any,1}, ::JuMP.#build, ::JuMP.Model) at ./<missing>:0
 [5] #solve#1333(::Bool, ::Bool, ::Bool, ::Array{Any,1}, ::Function, ::JuMP.Model) at /home/fredrikb/.julia/v0.6/JuMP/src/solvers.jl:168
 [6] #fit_statespace_jump!#600(::Int64, ::Int64, ::Float64, ::Bool, ::Array{Any,1}, ::Function, ::LTVModels.SimpleLTVModel{Float64}, ::Array{Float64,2}, ::Array{Float64,2}, ::Int64) at /home/fredrikb/.julia/v0.6/LTVModels/src/statespace_fit.jl:260
 [7] (::LTVModels.#kw##fit_statespace_jump!)(::Array{Any,1}, ::LTVModels.#fit_statespace_jump!, ::LTVModels.SimpleLTVModel{Float64}, ::Array{Float64,2}, ::Array{Float64,2}, ::Int64) at ./<missing>:0

with @stacktrace, I get an error in JuMP (which makes me unsure whether this is the right place to report this or not)

...
=1.0e-8, extend=true) => ErrorException("invalid index 1")
      - JuMP.solve(Minimization problem with:
 * 2 linear constraints
 * 797 SOC constraints
 * 3193 variables
Solver is Error showing value of type TraceCalls.Trace:
ERROR: BoundsError: attempt to access 1-element Array{SubString{String},1} at index [2]
Stacktrace:
 [1] show(::IOContext{Base.Terminals.TTYTerminal}, ::JuMP.Model) at /home/fredrikb/.julia/v0.6/JuMP/src/print.jl:167
 [2] show_args(::IOContext{Base.Terminals.TTYTerminal}, ::MIME{Symbol("text/plain")}, ::Tuple{JuMP.Model}) at /home/fredrikb/.julia/v0.6/TraceCalls/src/TraceCalls.jl:422
 [3] show_call_core(::IOContext{Base.Terminals.TTYTerminal}, ::MIME{Symbol("text/plain")}, ::TraceCalls.Trace) at /home/fredrikb/.julia/v0.6/TraceCalls/src/TraceCalls.jl:461
 [4] show(::IOContext{Base.Terminals.TTYTerminal}, ::MIME{Symbol("text/plain")}, ::TraceCalls.Trace) at /home/fredrikb/.julia/v0.6/TraceCalls/src/TraceCalls.jl:399
 [5] show(::IOContext{Base.Terminals.TTYTerminal}, ::MIME{Symbol("text/plain")}, ::TraceCalls.Trace) at /home/fredrikb/.julia/v0.6/TraceCalls/src/TraceCalls.jl:404 (repeats 2 times)
 [6] display(::Base.REPL.REPLDisplay{Base.REPL.LineEditREPL}, ::MIME{Symbol("text/plain")}, ::TraceCalls.Trace) at ./REPL.jl:122
 [7] display(::Base.REPL.REPLDisplay{Base.REPL.LineEditREPL}, ::TraceCalls.Trace) at ./REPL.jl:125
 [8] display(::TraceCalls.Trace) at ./multimedia.jl:194
 [9] hookless(::Media.##7#8{TraceCalls.Trace}) at /home/fredrikb/.julia/v0.6/Media/src/compat.jl:14
 [10] render(::Media.NoDisplay, ::TraceCalls.Trace) at /home/fredrikb/.julia/v0.6/Media/src/compat.jl:27
 [11] display(::Media.DisplayHook, ::TraceCalls.Trace) at /home/fredrikb/.julia/v0.6/Media/src/compat.jl:9
 [12] display(::TraceCalls.Trace) at ./multimedia.jl:194
 [13] eval(::Module, ::Any) at ./boot.jl:235
 [14] print_response(::Base.Terminals.TTYTerminal, ::Any, ::Void, ::Bool, ::Bool, ::Void) at ./REPL.jl:144
 [15] print_response(::Base.REPL.LineEditREPL, ::Any, ::Void, ::Bool, ::Bool) at ./REPL.jl:129
 [16] (::Base.REPL.#do_respond#16{Bool,Base.REPL.##26#36{Base.REPL.LineEditREPL,Base.REPL.REPLHistoryProvider},Base.REPL.LineEditREPL,Base.LineEdit.Prompt})(::Base.LineEdit.MIState, ::Base.AbstractIOBuffer{Array{UInt8,1}}, ::Bool) at ./REPL.jl:646

I hope you can tell me if this is an TraceCallsbug or a JuMP bug. Either way, this new package is super exciting! Found it through discourse.

[cstjean]

I would guess that it's an error in show(::IOContext{Base.Terminals.TTYTerminal}, ::JuMP.Model) at /home/fredrikb/.julia/v0.6/JuMP/src/print.jl:167. The Trace object seems to be correctly computed, but there's an error when displaying some part of it. You could probably fix it by writing TraceCalls.show_val(io::IO, mime, ::JuMP.Model) = write(io, "SomeModel"), but it's better to track it down and file an issue in JuMP. If you write trace_jump = @trace JuMP ...your_code...; with the ; at the end, then it won't be displayed, and you can inspect trace_jump gradually with prune. Or maybe try

for tr in collect(trace_jump) 
    for arg in tr.args
        if arg isa JuMP.Model println(arg) end
    end
end

This will print all Model objects in your trace, and hopefully can identify the one that cannot be printed properly.

[cstjean]

I just pushed a potential fix. It will display the trace correctly, but with <error displaying Model instance> where it gets the error from JuMP. Of course, it'd be nice to fix the broken show method in JuMP.

Please Pkg.checkout("TraceCalls") then try again your @stacktrace call. Let me know if it works.

[baggepinnen]

Pkg.checkout("TraceCalls") does fix the error, thanks! As for reporting in the JuMP repo, do you think it's a good idea to save the trace_jump to a file, e.g., using JLD and have them look at it, or there is no guarantee that it will open correctly on another system? Either way, I'll look into the JuMP error and report it over there

[baggepinnen]

When I run the code

for tr in collect(trace_jump) 
    for arg in tr.args
        if arg isa JuMP.Model println(arg) end
    end
end

The error does not occur, are you sure the same code is called by println(arg) as is called when the stacktrace is printed?

[cstjean]

Can you see the <error displaying Model>? If you can, you can get the object from the trace by indexing (eg. trace_jump[1,1]), then access the args/kwargs/value (trace_jump[1,1].args[2] - get second argument). show_val calls show(STDOUT, object) by default, so you can try calling that manually on the object, or dump it.

[cstjean]

JLD doesn't work, unfortunately, because it cannot save functions and modules. It should ideally be fixed over there, but I suppose we could implement a work-around.

[baggepinnen]

We found the source of the error in JuMP (https://github.com/JuliaOpt/JuMP.jl/issues/1092). It was due to JuMP expecting solver type names to follow a certain format, and the solver used did not. I'm letting the authors of JuMP decide how they want to handle it.

[cstjean]

Let me know if you have any other issue!