salcock
commented
1 year ago Thanks so much for reporting this. Sorry it has taken so long for me to get around to this issue.
You are correct about the cause of the issue. It only affects certain live capture formats because the trace_event() function for many formats actually falls back to calling trace_read_packet(), which ends up setting which_trace_start correctly. Only formats with their own custom event handling functions that don't end up calling trace_read_packet() themselves are affected by this.
I've fixed this issue in the current develop branch and the fix will be included in the next libtrace release, which should be in the next few days.
I've noticed an issue with using trace_event() for nonblocking IO. I think the issue crept in with this PR https://github.com/LibtraceTeam/libtrace/commit/37ee856d7e6692668e2d5822a2ab396bbb489945
In that PR, which_trace_start was added to the packet structure. which_trace_start is updated on the packet when trace_read_packet() is used, but not when trace_event() is used. Because of that, other API calls fail when the packet is used, like copy and applying filters. I think the fix should be easy, just setting which_trace_start in trace_event() just like in trace_read_packet().
I noticed there is one test that tests trace_event(). But the test does not try to use the packet, it only counts that packets are received. It might be good to expand this test a bit and ensure the packet is usable after trace_event() is called.