[lttng-dev] Wrong procname if tracepoint is used before fork

[fmarianirinel]

Hi,

>Based on the code found in liblttng-ust/lttng-context-procname.c [1] of
>lttng-ust,
>the procname is cached on the first hit and never reseted even after
>fork. The
>following comment indicate that an exec after fork will "clear" the
>cache. The
>comment also hint as to why we see identical value for procname event
>if prctl is
>used. The man page of lttng-ust also hint this limitation [2].
>
>[1] https://github.com/lttng/lttng-ust/blob/master/liblttng-ust/lttng-
>context-procname.c
>[2] https://lttng.org/man/3/lttng-ust/v2.10/#doc-_context_information
>The comment:
>
>    /*                                                                 
>      * We cache the result to ensure we don't trigger a system call
>for        * each event.                                               
>            * Upon exec, procname changes, but exec takes care of
>throwing away      * this cached version.                             
>                      * The procname can also change by calling
>prctl(). The procname should
>    * be set for a thread before the first event is logged within this 
>      * thread.                                                       
>        */                                                             
>     
>The man page:
>
>    Thread name, as set by exec(3) or prctl(2). It is recommended that
>programs
>    set their thread name with prctl(2) before hitting the first
>tracepoint for
>    that thread.
>

Created a patch with this suggestion:

---
diff --git a/include/lttng/ust-events.h b/include/lttng/ust-events.h
index caf7e63..fb1df1e 100644
--- a/include/lttng/ust-events.h
+++ b/include/lttng/ust-events.h
@@ -675,6 +675,7 @@ int lttng_add_cpu_id_to_ctx(struct lttng_ctx **ctx);
 int lttng_add_dyntest_to_ctx(struct lttng_ctx **ctx);
 void lttng_context_vtid_reset(void);
 void lttng_context_vpid_reset(void);
+void lttng_context_procname_reset(void);

 #ifdef LTTNG_UST_HAVE_PERF_EVENT
 int lttng_add_perf_counter_to_ctx(uint32_t type,
diff --git a/liblttng-ust/lttng-ust-comm.c b/liblttng-ust/lttng-ust-comm.c
index d98fae4..bd4d715 100644
--- a/liblttng-ust/lttng-ust-comm.c
+++ b/liblttng-ust/lttng-ust-comm.c
@@ -1988,6 +1988,7 @@ void ust_after_fork_child(sigset_t *restore_sigset)
                return;
        lttng_context_vpid_reset();
        lttng_context_vtid_reset();
+       lttng_context_procname_reset();
        DBG("process %d", getpid());
        /* Release urcu mutexes */
        rcu_bp_after_fork_child();
---

And I tested it with this reproducer:

https://github.com/Marian-Irinel/lttng-fork-procname-issue-reproducer.git

The results are what you would expect if you take in consideration the
man page. That is the child process can change it's name before leaving
any traces (could not do that before this, stuck with parent name if it
left traces before fork()).

Regards,
  Marian.

>We could force a reset of the cache on fork as done with the vtid and
>ptid [3] but
>this does not alleviate the prctl problem.
>
>[2]
https://github.com/lttng/lttng-ust/blob\/6d9b54d845b08d54d3f483f1130b499516588db3/liblttng-ust/lttng-ust-comm.c#L2010
>
>The real solution would probably be to "shim" prctl and catch the change of
>procname.
>
>Mathieu Desnoyers most probably have more insight regarding all this.
>
>Cheers
>
>--
>Jonathan Rajotte-Julien
>EfficiOS