Project

General

Profile

Actions

Feature #1326

closed

Tracing doesn't work because liblttng-ust-tracepoint.so.1 is not in dynamic linker path

Added by Simon Marchi 11 months ago. Updated 6 months ago.

Status:
Won't fix
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
10/04/2021
Due date:
% Done:

0%

Estimated time:

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.

Actions #1

Updated by Simon Marchi 11 months ago

There was a similar feature request on the mailing list: https://lists.lttng.org/pipermail/lttng-dev/2021-July/030040.html

Actions #2

Updated by Mathieu Desnoyers 11 months ago

  • Tracker changed from Bug to Feature
  • Status changed from New to Confirmed
Actions #4

Updated by Michael Jeanson 6 months ago

  • Status changed from Confirmed to Won't fix
Actions

Also available in: Atom PDF