Re: [PATCH 1/1] libtracecmd: fix memory leak on partial reverse iteration

["MOESSBAUER, Felix" <felix.moessbauer@siemens.com>]

On Fri, 2025-11-21 at 12:01 -0500, Steven Rostedt wrote:
> On Fri, 21 Nov 2025 14:47:49 +0100
> Felix Moessbauer <felix.moessbauer@siemens.com> wrote:
> 
> > When calling tracecmd_iterate_events_reverse with a callback that does
> > not always return 0, the trace is only partially iterated. By that, the
> > non-iterated records are leaked, resulting in the error:
> > 
> >  1 pages still allocated on cpu <cpu>
> > 
> > We fix this by always iterating the remaining events on all selected
> > CPUs. In the full iteration case, this stops on the first record as this
> > is already zero. In the partial iteration case, all remaining records
> > are freed, which is - by construction of the records list - at max a
> > page size.
> > 
> > Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
> > ---
> > Note, that this bug has been reported in [1].
> > 
> > [1] https://lore.kernel.org/linux-trace-devel/0b4fb4b774a8754ed86a9212f0a253304a41245c.camel@siemens.com/
> > 
> 
> Thanks for the report. I actually found two bugs here.

Hi,

while thinking about it again, I noticed that the callback based
iteration interface relies on some assumptions which are not
documented. While probably obvious, it should be documented what is NOT
allowed to be done inside the callback (i.e. calling any 
tracecmd_iterate_* function, but also calling tracecmd_read_* and
alike?).

Best regards,
Felix

-- 
Siemens AG
Linux Expert Center
Friedrich-Ludwig-Bauer-Str. 3
85748 Garching, Germany