Project

General

Profile

Actions

Feature #717

open

Better validation of tracepoint provider headers?

Added by Daniel U. Thibault about 10 years ago. Updated about 10 years ago.

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

0%

Estimated time:

Description

I fooled around to try and break the LTTng tracepoint provider preparation process at the level of the event field names. Turns out the literals supplied to the ctf_* macros as arguments for TP_FIELDS are pretty robust. Maybe too robust.

If you supply a non-identifier (see ISO/IEC 9899:TC2 (9899:1999) at 6.4.2 and Annex D) such as for instance "named name" or ".name", the tracepoint provider header compiles, links and packages into an .so without a hitch. The instrumented application likewise. Tracing also works flawlessly, producing a trace on disk. But when babeltrace tries to read it, it complains and gives up, with messages like:

[error] at line 110: token "name": syntax error, unexpected IDENTIFIER, expecting SEMICOLON or COMMA
[...]

(for "named name") or

[error] at line 110: token ".": syntax error, unexpected DOT, expecting SEMICOLON or COMMA
[...]

(for ".name")

There isn't much that can be done to prevent this. I would recommend merely amending the tracepoint provider samples slightly, like this:

    /*
     * The ctf_string macro takes a C string and writes it into a field
     * named "message" (any C identifier will do for the field name)
     */
        ctf_string(message, text)
Actions #1

Updated by Mathieu Desnoyers about 10 years ago

  • Project changed from LTTng-tools to LTTng-UST
Actions

Also available in: Atom PDF