Re: [lttng-dev] Babeltrace trimmer segfaults on custom trace

[Simon Marchi via lttng-dev <lttng-dev@lists.lttng.org>]

On 2021-05-04 10:21 a.m., Dimitri Scheftelowitsch via lttng-dev wrote:
> 
> Hi,
> 
> as mentioned on the IRC channel, babeltrace2 (both HEAD and current release in the lttng Ubuntu 20 repo) aborts with a violated precondition in `bt_clock_snapshot_get_ns_from_origin` on some custom traces we created. One of these traces is attached. It seems that the offending message is of type `BT_MESSAGE_TYPE_PACKET_BEGINNING`. What is confusing is that the pretty-printer does not seem to be influenced by this, and furthermore, I am not sure that this type of message actually requires a timestamp (at least if I understood the CTF spec correctly). Is this an issue with the trace itself or rather with babeltrace2?
> 
> To reproduce: `babeltrace2 nvctf --timerange="17:09:13.034123470,17:29:18.034216302"`.
> 
> Any help would be appreciated.

Hi Dimitri,

Thanks for providing a trace, the issue was very easy to reproduce.

There are indeed some missing checks in the trimmer code and the lib
code to avoid hitting some asserts when dealing with packets that have
no timestamps (clock snapshots).  I have a beginning of a patch here:

  https://review.lttng.org/c/babeltrace/+/5677

However, once that is fixed, I hit:

  https://github.com/efficios/babeltrace/blob/534d93a8b2ba86f56dfdf6aa7a10911da5f6432c/src/plugins/utils/trimmer/trimmer.c#L1284-L1290

If the trace has packets, the trimmer component currently requires
packets to have timestamps.   It would be possible for the trimmer to
support packet messages without timestamps, but support for it is not
implemented right now.  I tried to see if it would be possible for you
to just not use packets, but unfortunately I stumbled on what looks like
a bug in the CTF metadata parser, it hardcodes whether streams classes
have packets to true:

  https://github.com/efficios/babeltrace/blob/534d93a8b2ba86f56dfdf6aa7a10911da5f6432c/src/plugins/ctf/common/metadata/ctf-meta-translate.c#L576

So when I tried removing the packet from your trace, trimmer was still
unhappy about it.

The easiest immediate fix for you would probably be to add some
timestamps to your packets.  Looking at an LTTng trace, we can see:

struct packet_context {
        uint64_clock_monotonic_t timestamp_begin;
        uint64_clock_monotonic_t timestamp_end;
        uint64_t content_size;
        uint64_t packet_size;
        uint64_t packet_seq_num;
        unsigned long events_discarded;
        uint32_t cpu_id;
};

and

stream {
        id = 0;
        event.header := struct event_header_large;
        packet.context := struct packet_context;
};

So you can try adding a packet context with the two "timestamp" fields.
Just make sure that timestamp_begin is <= your first event's timestamp
and timestamp_end is >= your last event's timestamp.

And of course, the other option is to fix Babeltrace, if you have some
cycles to spare.

Simon
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev