improve interaction of task switches and finally blocks (#12485)

[JeffBezanson]

This does two things intended to improve the state of affairs in issue #12485:

• Save the exception to be rethrown around the code in a finally block
• Set bt_size=0 on task switch. Since we don't remember which task the backtrace came from, it must be associated with the current task or else not exist.

Behavior with this change:

julia> t = @schedule try
              while true; sleep(1); end
              catch e
              isa(e,InterruptException) || rethrow(e)
              end
Task (waiting) @0x00007fb118dc6590

julia> try
              error("You will never see me")
              catch e
              rethrow(e)
              finally
              Base.throwto(t,InterruptException())
              end
ERROR: You will never see me

We give the correct exception, but the backtrace is lost on task switch since nobody saved it and we don't save it automatically. Basically, somebody has to call catch_backtrace between catching and the next throw or task switch. This doesn't interfere with task backtraces, since task_done_hook now calls catch_backtrace. I think this will make things less confusing; seeing no backtrace tells you that it was lost, and is better than a backtrace from some random different place.

[JeffBezanson]

Seeing some odd blas-related error on OSX:

ERROR: LoadError: On worker 5:

LoadError("/private/tmp/julia/share/julia/test/linalg/arnoldi.jl",8,ErrorException("error compiling naupd: could not load library \"libarpack\"\ndlopen(libarpack.dylib, 1): Library not loaded: /usr/local/opt/openblas-julia/lib/libopenblasp-r0.2.12.dylib\n  Referenced from: /usr/local/opt/arpack-julia/lib/libarpack.dylib\n  Reason: image not found"))

 in aupd_wrapper at linalg/arpack.jl:49

 in eigs at linalg/arnoldi.jl:127

 in eigs at linalg/arnoldi.jl:7

 in anonymous at no file:35

 in include_string at loading.jl:225

 in include_from_node1 at /private/tmp/julia/lib/julia/sys.dylib

 in runtests at /private/tmp/julia/share/julia/test/testdefs.jl:179

 in anonymous at multi.jl:889

 in run_work_thunk at multi.jl:642

 in anonymous at task.jl:889

while loading /private/tmp/julia/share/julia/test/runtests.jl, in expression starting on line 13

Anybody know what this is? cc @staticfloat @ViralBShah

[staticfloat]

This often happens if a library that OpenBLAS wants to load (e.g.
libgfortran) isn't where it expects it. Try removing openblas-julia and
re-adding it. This happens every now and then when a new gcc (and
subsequently libgfortran) gets released and I screw up the version bump.
Make sure to update brew as well.

On Mon, Aug 10, 2015, 3:45 PM Jeff Bezanson notifications@github.com
wrote:

Seeing some odd blas-related error on OSX:

ERROR: LoadError: On worker 5:

LoadError("/private/tmp/julia/share/julia/test/linalg/arnoldi.jl",8,ErrorException("error compiling naupd: could not load library "libarpack"\ndlopen(libarpack.dylib, 1): Library not loaded: /usr/local/opt/openblas-julia/lib/libopenblasp-r0.2.12.dylib\n Referenced from: /usr/local/opt/arpack-julia/lib/libarpack.dylib\n Reason: image not found"))

in aupd_wrapper at linalg/arpack.jl:49

in eigs at linalg/arnoldi.jl:127

in eigs at linalg/arnoldi.jl:7

in anonymous at no file:35

in include_string at loading.jl:225

in include_from_node1 at /private/tmp/julia/lib/julia/sys.dylib

in runtests at /private/tmp/julia/share/julia/test/testdefs.jl:179

in anonymous at multi.jl:889

in run_work_thunk at multi.jl:642

in anonymous at task.jl:889

while loading /private/tmp/julia/share/julia/test/runtests.jl, in expression starting on line 13

Anybody know what this is? cc @staticfloat
https://github.com/staticfloat @ViralBShah
https://github.com/ViralBShah

—
Reply to this email directly or view it on GitHub
#12541 (comment).

[JeffBezanson]

@Keno @vtjnash any thoughts on this change?

[vtjnash]

i think this is a good improvement. it will be nice to also copy the backtrace at some point, but i don't see any reason that should delay this.

can we deprecate jl_rethrow at the same time? user code might have the same issue, so it might be better to just always be explicit.