Fix: race between lttng-ust getenv() and application setenv()
authorMathieu Desnoyers <mathieu.desnoyers@efficios.com>
Fri, 10 Mar 2017 23:08:25 +0000 (18:08 -0500)
committerMathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mon, 20 Mar 2017 14:00:56 +0000 (10:00 -0400)
commit4925438891788d3abc0520fd3d09d3f4003d992d
tree9d2245dfa1bec7424cfd998ba577bb7a75197158
parent0be120c87e5a2b2099e5858b16f4bb23f81acda6
Fix: race between lttng-ust getenv() and application setenv()

The LTTng-UST listener threads invoke getenv(), which can cause issues
if the application issues setenv() concurrently. This is a legitimate
use by the application because it may have a single thread and not be
aware that it runs with liblttng-ust.

Fix this by keeping our own environment variable table for the variables
we care about. Initialize this table within the lttng-ust library
constructor, when we don't race with the application.

As this thread shows:
https://sourceware.org/bugzilla/show_bug.cgi?id=5069#c10

getenv() does _not_ appear to be thread-safe if an application uses
setenv() or putenv().

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
liblttng-ust-ctl/ustctl.c
liblttng-ust/Makefile.am
liblttng-ust/getenv.c [new file with mode: 0644]
liblttng-ust/getenv.h
liblttng-ust/lttng-clock.c
liblttng-ust/lttng-getcpu.c
liblttng-ust/lttng-ust-comm.c
liblttng-ust/lttng-ust-statedump.c
snprintf/core.c
This page took 0.026756 seconds and 4 git commands to generate.