Good catch Philippe,
I pushed a commit that enforces validation of event class/instance
prototypes (TP_ARGS()) at compile-time.
It is pushed into lttng-ust master as:
commit c75c0422c64f33c0102e1778cecc812c58b700e5
Author: Mathieu Desnoyers <mathieu.desnoy...@efficios.com>
Date: Thu Sep 27 15:21:16 2018 -0400
Fix: check for event class/instance prototype mismatch
The TP_ARGS() for an event instance belonging to an event class
must have compatible types with the event class TP_ARGS().
Failure to follow this rule leads to a prototype mismatch between the
tracepoint call site and the probe function. A common effect perceived
is that events with prototype mismatch between call site and probe
function are never traced.
Fix this by enforcing a compile-time check of the event instance and
class prototypes, similarly to what is done in LTTng modules.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoy...@efficios.com>
And cherry-picked into lttng-ust 2.11, 2.10, 2.9 stable branches,
Thanks!
Mathieu
----- On Sep 27, 2018, at 1:51 PM, Philippe Proulx eeppelitel...@gmail.com
wrote:
> In `resolution_management_tp.tp`, can you try using the exact same
> `TP_ARGS` content for both `TRACEPOINT_EVENT_INSTANCE` (also matching
> the `TP_ARGS` content of `TRACEPOINT_EVENT_CLASS`)? It's the only
> difference I can see.
>
> Philippe Proulx
> Philippe Proulx
>
>
> On Thu, Sep 27, 2018 at 12:15 PM John O'Sullivan
> <john.osulli...@blackbox.com> wrote:
>>
>> I am really struggling trying to get user space tracing working predictably
>> and
>> consistently and would appreciate some help.
>>
>>
>> I created a trace event called
>>
>> kvm_server:new_connection_tracepoint (see attached), I then use lttng-gen-tp
>> to
>> generate the .c and .h files which I link to the program and call with
>>
>> tracepoint(kvm_server, new_connection_tracepoint, .................)
>>
>> This appears predictably in my traces
>>
>> However if I call my second tracepoint (see attached)
>>
>> tracepoint(resolution_management, resolution_management_tracepoint,.......)
>>
>> It never appears in any of the traces
>>
>> I can see no significant difference between the two definitions.
>>
>>
>> I then created a third trace definition called simple_example (see attached)
>>
>> tracepoint(simple_example, simple_example_tracepoint, .....)
>>
>> This again appears in the trace
>>
>>
>> I start the tracing using
>>
>> lttng enable-event -u -a # enable user-space tracing
>>
>> I then use babel trace to dump the trace,
>>
>>
>> 'kvm_server' and 'simple_example' appear in the trace, resolution_management
>> does not.
>>
>>
>>
>> Any idea why the resolution_management tracepoint does not appear in any
>> traces
>> or is there some way of debugging the tracecall macro itself?
>>
>>
>> regards
>>
>> John
>>
>>
>> ________________________________
>>
>> This email and any files transmitted with it are confidential and are
>> intended
>> for the sole use of the individual to whom they are addressed. Black Box
>> Corporation reserves the right to scan all e-mail traffic for restricted
>> content and to monitor all e-mail in general. If you are not the intended
>> recipient or you have received this email in error, any use, dissemination or
>> forwarding of this email is strictly prohibited. If you have received this
>> email in error, please notify the sender by replying to this email.
>> _______________________________________________
>> lttng-dev mailing list
>> lttng-dev@lists.lttng.org
>> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> _______________________________________________
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
