How to get thread names from a core dump?-CodePudding

I have a multi-threaded program, where each thread is assigned a unique name with help of pthread_setname_np. If I attach to a running program with gdb, I can see their names:

(gdb) i th
  Id   Target Id                                            Frame
* 1    Thread 0x7f883dba1200 (LWP 3867757) "main"           __pthread_clockjoin_ex (threadid=140222870320896, thread_return=0x0, clockid=<optimized out>, abstime=<optimized out>, block=<optimized out>)
    at pthread_join_common.c:145
  2    Thread 0x7f883477f700 (LWP 3867759) "log_aggregator" 0x00007f883dc8026f in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=0x7f883477b220, rem=0x7f883477b220)
    at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78

Note main and log_aggregator names. However, If I make a core dump and then load this dump with gdb, I don't see the names:

$ gcore 3867757
...
Saved corefile core.3867757
...
$ gdb -c core.3867757 my_program
GNU gdb (Ubuntu 10.2-0ubuntu1~20.04~1) 10.2
...
(gdb) i th
  Id   Target Id                           Frame
* 1    Thread 0x7f883dba1200 (LWP 3867757) __pthread_clockjoin_ex (threadid=140222870320896, thread_return=0x0, clockid=<optimized out>, abstime=<optimized out>, block=<optimized out>)
    at pthread_join_common.c:145
  2    Thread 0x7f883477f700 (LWP 3867759) 0x00007f883dc8026f in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=0x7f883477b220, rem=0x7f883477b220)
    at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78

How do I get thread names in this case? Or should I create core file differently to put them in the core file? I examined coredump_filter option, but did not find anything related. I also discovered this discussion at narkive mailing list archive, but it does not provide an answer, only a suggestion that this might be impossible.

CodePudding user response：

My next question would be is there any way this /proc/self/task/[tid]/comm

The /proc/.../comm is not a real file, it's a representation of kernel data structures related to this task generated on-demand (when you try to read that "file").

The current->comm field that you are looking for is not mentioned in the binfmt_elf.c file (which is where other core dumping code is), so it's probably not saved.

In fact this is easily confirmed by running a test program generating a random string, calling pthread_setname_np, dumping core and then running strings -a core | grep $string, which produces no output.

There is no fundamental reason the current->comm can not be saved in the core, but currently it isn't.

P.S. Usually looking at thread apply all where is enough to distinguish different threads, so the unique thread name is redundant and unnecessary.