Bug #1306


Detect probe providers built against old lttng-ust (.so.0) in lttng-ust .so.1

Added by Mathieu Desnoyers almost 2 years ago. Updated 11 months ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


We should ensure the new lttng-ust (.so.1) refuses old probe providers. Likewise for old tracepoint instrumentation.

We should also check whether it might be possible for an application and its shared libraries to end up linking against both .so.0 and .so.1 within the same process, for instance if only some of those are rebuilt. If this can happen, we should provide some mechanism to detect this.

Actions #1

Updated by Mathieu Desnoyers almost 2 years ago

For the part about refusing old tracepoint providers and old tracepoint modules, this is solved by having changed the API symbols for the registration functions in .so.1. This means the old applications/probes won't ever try to call the new API, even due to a weird build misconfiguration, because those have new names.

Actions #2

Updated by Mathieu Desnoyers almost 2 years ago

For the part where we want to ensure there are not lttng-ust nor lttng-ust-tracepoint libraries from .so.0 and .so.1 loaded in the same process, this gerrit review is an attempt at detecting this from .so.1: Detect unsupported use of .so.0 and .so.1 libraries within same process

Actions #3

Updated by Mathieu Desnoyers almost 2 years ago

However, I am concerned about use-cases where a process is linked against multiple shared libraries, some of which have a dependency against liblttng-ust{,-tracepoint}.so.0, where it would not be practical to rebuild and deploy all libraries in locked-step.

In this kind of scenario, one possible approach we could consider is to provide a "stub" liblttng-ust{,-tracepoint}.so.0, which means the tracepoint instrumentation and tracepoint providers in the applications would try to register themselves to the stub, but would be ignored. I am not entirely sure this is practical nor something we really want to do though.

I am also unsure whether this is a scenario we really want to support.

Actions #4

Updated by Michael Jeanson over 1 year ago

  • Status changed from New to Resolved

Fixed in 6f78600e9600f413ebdf532e154d8946725d83fd

Actions #5

Updated by Michael Jeanson 11 months ago

  • Target version changed from 41 to 2.13

Also available in: Atom PDF