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
