Hi all,

I followed Shintaro's suggestions from the previous list email thread and was able to get a stack dump routine that works as expected.  For all pools under my control I can see stack information like this for each ULT, with stack unwinding:

== pool (0x557d5b8c4580) ==
=== ULT (0x7f47429590c1) ===
id        : 0
ctx       : 0x7f4742959120
p_ctx    : 0x7f4742958fe0
p_link   : (nil)
stack     : 0x7f47427590c0
stacksize : 2097152
#0 0x7f4744461760 in ythread_unwind_stack () <+16> (RSP = 0x7f4742959010)
#1 0x7f474445e3dd in ABT_thread_yield () <+157> (RSP = 0x7f4742959020)
#2 0x7f474447e255 in __margo_hg_progress_fn () <+645> (RSP = 0x7f4742959040)
#3 0x7f474446381e in ABTD_ythread_func_wrapper () <+30> (RSP = 0x7f47429590b0)
#4 0x7f47444639c1 in make_fcontext () <+33> (RSP = 0x7f47429590c0)
00007f47427590c0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
00007f47427590e0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
...

That only works for ULTs that are literally in the pool, though, I think.  I don't believe that I am getting information for ULTs that are executing (and thus are not presently in a pool data structure).

Is there any way to accomplish that?

I tried to at least get the caller's own stack at least by doing something like this:

    ABT_thread_self(&self);
    ABT_info_print_thread_stack(outfile, self);

That almost works, but I'm just getting the raw address information and not the translated stack unwinding:

p_ctx    : 0x7f4742758fb8
p_link   : (nil)
stack     : 0x7f4742559000
stacksize : 2097152
00007f4742559000: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
00007f4742559020: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
...

For completeness it would be nice if the caller's stack were also human readable, and even better if I could somehow find stack information for ULTs executing on other ESs as well.

For our use case we typically spawn many detached threads into a service pool, so we aren't tracking thread references.

thanks,

-Phil