[argobots-discuss] dumping stack information for running ULTs
Phil Carns
carns at mcs.anl.gov
Wed Apr 14 18:44:36 CDT 2021
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.argobots.org/pipermail/discuss/attachments/20210414/ad54c367/attachment.html>
More information about the discuss
mailing list