tasks-debugging: make it possible to get the backtrace of a task

[vtjnash]

debugging-only, this adds some internal utility functions for introspecting task state while the process is stopped

this should work for any non-copy stack task,
although gdb puts in a special hook to the longjmp
which causes it to crash when gdb returns :/

to work around that gdb issue, you may want to
use the more compatible task switching backend:

diff --git a/src/julia_threads.h b/src/julia_threads.h
index 1da831bafe..8fe282d731 100644
--- a/src/julia_threads.h
+++ b/src/julia_threads.h
@@ -22,0 +23,2 @@
+#define JL_HAVE_UCONTEXT
+

This also exports the list of all live (currently running or suspended)
tasks which have real stacks (the non-copy-stack tasks) on the current
thread, so that they can be read from gdb or Julia.

[vchuravy]

As an aside, I would love to be able to send SIGQUIT to a julia program and dump the stacktraces for every task. It seems Go may be using both SIGABRT and SIGQUIT, and there is some precedent in JVM that SIGQUIT only prints the backtraces, but doesn't actually terminate the program.

[vtjnash]

We've usually done that on SIGINFO (or SIGUSR1 for linux)

[vchuravy]

The nice thing about SIGQUIT is that it is Ctrl+\ on Unix

[c42f]

This looks useful. I won't claim to follow what's really going on in jl_backtrace_fiber 😬

[staticfloat]

What needs to be done here to get this merged in? I would really like to be able to debug my tasks to see if there are tasks escaping, taking up memory, etc...

[StefanKarpinski]

Bump. Having this would be really useful for debugging pkg server issues which are fairly urgent for 1.5 (yes, this won't be in 1.5 but the server doesn't have to run 1.5, it's the fact that once 1.5 is released, all Pkg clients will talk to the server by default that makes this urgent).

[vtjnash]

Okay, I took a slightly different approach and fixed the JL_HAVE_UNW_CONTEXT backend, and made that the default for most platforms. The downside is that it's not quite as fast:

julia> t = @task while true; yieldto(Base.roottask); end; @btime yieldto($t)
  562.092 ns (0 allocations: 0 bytes) # PR
  179.916 ns (0 allocations: 0 bytes) # MASTER

compare with #13099 (comment) —this gives up most of the speed up we got from avoiding COPY_STACKS.

But compare also to:

julia> @btime Base.process_events()
  493.830 ns (0 allocations: 0 bytes)

which we do on (nearly) every task switch, and the impact should not be too bad overall.

With additional effort per-platform (already done on Windows, where libunwind doesn't exist), we can resume using the current setjmp.

[staticfloat]

What constitutes a 'live' task?

julia> ccall(:jl_live_tasks, Vector, ())
3-element Vector{Any}:
 Task (runnable) @0x00007f8905200010
 Task (runnable) @0x00007f8905200450
 Task (runnable) @0x00007f890599fb90

julia> @async nothing
Task (done) @0x00007f8908950450

julia> ccall(:jl_live_tasks, Vector, ())
4-element Vector{Any}:
 Task (runnable) @0x00007f8905200010
 Task (runnable) @0x00007f8905200450
 Task (runnable) @0x00007f890599fb90
 Task (done) @0x00007f8908950450

I was kind of expecting that 4th task to not be returned.

[vtjnash]

okay, I've fixed that (removed dead tasks), though linux performance cost to making this the default is seeming unacceptable there (the numbers above were for masOS):

julia> t = @task while true; yieldto(Base.roottask); end; @btime yieldto($t)
  198.808 ns (0 allocations: 0 bytes) # master
  12.426 μs (0 allocations: 0 bytes) # PR

profile shows that libunwind is doing a lot of dumb stuff inside unw_resume.

[rgobbel]

This line, and line 60, refer to ctx, but that variable is no longer defined, so this cannot possibly compile. What's supposed to happen here?