Identify UST threads by changing thread names
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hi Raphaël,
Quoted 10 lines
Hi,
This is an RFC patch for comments and ideas about how this should be done. In recent work I've been doing, I found out that some UST- instrumented userspace process was preempting itself. Looking further, it was not the same TID, but the same process name. These processes were LTTng-UST listener threads, but were not identified as so. Adding a simple symbol, such as "-ust" or "-lttng" at the end of the process name would help to identify such process directly in the generated trace.
Do you know if the name of these listener threads can be set in their constructor, directly when they are brought into this world ?
Quoted 10 lines
You'll find below two different implementations with their pros and cons, for which the "-ust" symbol was choosen:
1/ An implementation using prctl
It works properly on Linux, but I didn't find a way to make it work under FreeBSD, hence the empty function in FreeBSD case (keeping the situation as it is now).
Quoted 8 lines
Raphaël Beamonte (1):
Add -ust to the name of UST threads of the applicationliblttng-ust/compat.h | 22 ++++++++++++++++++++++ liblttng-ust/lttng-ust-comm.c | 2 ++ 2 files changed, 24 insertions(+)
I prefer this one. It is less complex, in my opinion.
Quoted 9 lines
2/ An implementation using pthread
It works on both Linux and FreeBSD, but requires to add a link to the pthread library in liblttng-ust Makefile.am. Also, this approach relies on the presence of thepthread_setname_npfunction, which was included in glibc 2.12, meaning it will not work with older versions (but this should not be a problem?)
Quoted 8 lines
Raphaël Beamonte (1):
Add -ust to the name of UST threads of the applicationliblttng-ust/Makefile.am | 1 + liblttng-ust/compat.h | 35 +++++++++++++++++++++++++++++++++++ liblttng-ust/lttng-ust-comm.c | 2 ++ 3 files changed, 38 insertions(+)
Perhaps the availability of pthread_setname_np and/or pthread_set_name_np (you have both names in your patch 2) should be ascertained in another venue, such as the configure.ac -- where it belongs.
Quoted 8 lines
I'll wait for your comments and ideas on that subject.
Thanks,
Raphaël
_______________________________________________
lttng-dev mailing list
[email protected]
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev