[lttng-dev] [RFC PATCH 0/2] Identify UST threads by changing thread names

[Sebastien Boisvert]

Hi Raphaël,

> 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 ?

> 
> 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).
> 
> Raphaël Beamonte (1):
>   Add -ust to the name of UST threads of the application
> 
>  liblttng-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.

> 
> 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 the
> 	pthread_setname_np function, which was included in glibc
> 	2.12, meaning it will not work with older versions (but
> 	this should not be a problem?)
> 
> Raphaël Beamonte (1):
>   Add -ust to the name of UST threads of the application
> 
>  liblttng-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.

> 
> 
> I'll wait for your comments and ideas on that subject.
> 
> Thanks,
> Raphaël
> 
>