LTTng » LTTng-tools

In user-space, two applications may be using different tracepoint providers that register their events under the same provider name and event name (I guess this could also happen in kernel space if two modules are loaded with user-designed providers that similarly clashing events). Granted, not an usual occurrence but it could happen, for instance if a long-running trace sees an application undergoing an upgrade between executions.

The problem is that unless the buffering scheme is per-processID, the metadata will only capture the first event registration. The trace will be captured correctly, but babeltrace won't be able to correctly decode the second application's events. This can either lead to babeltrace quitting (typically with "[error] Event id nn is outside range") or generating incorrectly labelled event payloads, even spurious additional events.

This is not an easy bug to solve. At first glance it would seem the metadata should be enriched with timestamped event definitions, but by itself this won't be enough because the trace would still need to have some way to correctly disambiguate same-name events as they come in.

The bug should not be dismissed as "user error" because it could be used as part of an attack to disable system monitoring (consider what would happen if two same-name-but-different-payloads events were fed to a live trace analyzer).