[lttng-dev] User Space Tracing

[Mathieu Desnoyers]

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.desnoyers at 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.desnoyers at 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 eeppeliteloop at 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.OSullivan at 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 at lists.lttng.org
>> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com