Project

General

Profile

Actions

Bug #720

open

Disambiguating fully qualified event names, timestamp-sensitive metadata

Added by Daniel U. Thibault almost 11 years ago. Updated over 9 years ago.

Status:
Confirmed
Priority:
Low
Assignee:
-
Target version:
Start date:
01/16/2014
Due date:
% Done:

0%

Estimated time:

Description

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).


Related issues 1 (0 open1 closed)

Related to Babeltrace - Bug #698: babeltrace sometimes ignores changing metadata rendering hintsWon't fix11/26/2013

Actions
Actions

Also available in: Atom PDF