I confirm it fixes the problem I was seeing. Thanks,
Julien On 15-07-30 12:53 PM, Jérémie Galarneau wrote: > Here is my proposed fix. Can you test it on your end? > > https://github.com/jgalar/lttng-tools/commits/sessiond-agent-crash > > commit 5e249e09a2bd68f96e546bf83b4710596518f675 > Author: Jérémie Galarneau <[email protected] > <mailto:[email protected]>> > Date: Thu Jul 30 12:48:52 2015 -0400 > > Clean-up: Move agent_apps_ht_by_sock definition to main.c > > Signed-off-by: Jérémie Galarneau <[email protected] > <mailto:[email protected]>> > > commit 1af8b99faa625033f9e0c2a6eaa9b3006cfadadd > Author: Jérémie Galarneau <[email protected] > <mailto:[email protected]>> > Date: Thu Jul 30 12:46:56 2015 -0400 > > Fix: Initialize global agent_apps_ht_by_sock on session daemon launch > > Signed-off-by: Jérémie Galarneau <[email protected] > <mailto:[email protected]>> > > > Jérémie > > > On Thu, Jul 30, 2015 at 12:02 PM, Jérémie Galarneau > <[email protected] <mailto:[email protected]>> > wrote: > > > > On Thu, Jul 30, 2015 at 11:12 AM, Julien Desfossez > <[email protected] <mailto:[email protected]>> wrote: > > Commit 6a4e403927ffef4cae8726064dcf53c463eb128c introduced a bug > where > we could end up iterating over the agent_apps_ht_by_sock > regardless if > it was allocated or not (only when the sessiond is launched as > root). > > Steps to reproduce: > $ sudo lttng-sessiond -d > $ lttng-sessiond > Error: Already running daemon. > Segmentation fault (core dumped) > > Signed-off-by: Julien Desfossez <[email protected] > <mailto:[email protected]>> > --- > src/bin/lttng-sessiond/main.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/src/bin/lttng-sessiond/main.c > b/src/bin/lttng-sessiond/main.c > index 91dd047..5840165 100644 > --- a/src/bin/lttng-sessiond/main.c > +++ b/src/bin/lttng-sessiond/main.c > @@ -677,7 +677,9 @@ static void sessiond_cleanup(void) > } > > DBG("Cleaning up all agent apps"); > - agent_app_ht_clean(); > + if (is_root) { > + agent_app_ht_clean(); > + } > > > This will leak the hash table if the session daemon was launched as > an unprivileged user. However, the problem can also be reproduced by > launching two session daemons under the same unprivileged user. > > The real issue here seems to be that the session daemon will enter > the "exit_init_data" code path before creating the hash table if it > can't acquire the lock file and that there are no NULL checks > performed during the sessiond_cleanup(). > > Thanks, > Jérémie > > > DBG("Closing all UST sockets"); > ust_app_clean_list(); > -- > 1.9.1 > > > > > -- > Jérémie Galarneau > EfficiOS Inc. > http://www.efficios.com > > > > > -- > Jérémie Galarneau > EfficiOS Inc. > http://www.efficios.com > > > _______________________________________________ > lttng-dev mailing list > [email protected] > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev > _______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
