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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With