Project

General

Profile

Actions

Bug #1306

closed

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

Added by Mathieu Desnoyers almost 3 years ago. Updated about 2 years ago.

Status:
Resolved
Priority:
Normal
Target version:
Start date:
04/13/2021
Due date:
% Done:

0%

Estimated time:

Description

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 3 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 3 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:

https://review.lttng.org/c/lttng-ust/+/5616 Detect unsupported use of .so.0 and .so.1 libraries within same process

Actions #3

Updated by Mathieu Desnoyers almost 3 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 almost 3 years ago

  • Status changed from New to Resolved

Fixed in 6f78600e9600f413ebdf532e154d8946725d83fd

Actions #5

Updated by Michael Jeanson about 2 years ago

  • Target version changed from 41 to 2.13
Actions

Also available in: Atom PDF