Feature #1326
closedTracing doesn't work because liblttng-ust-tracepoint.so.1 is not in dynamic linker path
0%
Description
I started looking at this because of tests/regression/ust/multi-lib/test_multi_lib
failing in my lttng-tools development tree. I install the development builds of urcu and lttng-ust in /tmp/lttng
, and /tmp/lttng/lib
is not part of my dynamic linker's default lookup path.
The multi-lib test consists of an application defining tracepoints, but not probes, and a shared library containing probes. So the application does not link directly with liblttng-ust-tracepoint.so
, only the shared library does. When the application starts, an lttng-ust
-provided constructor tries to dlopen liblttng-ust-tracepoint.so.1
(https://github.com/lttng/lttng-ust/blob/81b2d23800224648edd5850dd43b78d00b668a5e/include/lttng/tracepoint.h#L404-L408) in order to register tracepoints. Since liblttng-ust-tracepoint.so.1
is in /tmp/lttng/lib
, not in the dynamic linker's path, the dlopen fails, the application's tracepoints are not registered, and those tracepoints never work.
Fixing it requires setting LD_LIBRARY_PATH or using -rpath.
I think it would make sense to try to dlopen liblttng-ust-tracepoint.so.1
by absolute path directly, in this case /tmp/lttng/lib/liblttng-ust-tracepoint.so.1
.
Updated by Simon Marchi over 3 years ago
There was a similar feature request on the mailing list: https://lists.lttng.org/pipermail/lttng-dev/2021-July/030040.html
Updated by Mathieu Desnoyers over 3 years ago
- Tracker changed from Bug to Feature
- Status changed from New to Confirmed
Updated by Simon Marchi over 3 years ago
Proposed patch: https://review.lttng.org/c/lttng-ust/+/6481
Updated by Michael Jeanson about 3 years ago
- Status changed from Confirmed to Won't fix