Re: [PATCH 1/1] libtracecmd: fix memory leak on partial reverse iteration
"MOESSBAUER, Felix" <[email protected]> Mon, 24 Nov 2025 09:14:06 +0000
| Newsgroups | org.kernel.vger.linux-trace-devel |
|---|---|
| Message-ID | <[email protected]> |
On Fri, 2025-11-21 at 12:01 -0500, Steven Rostedt wrote: > On Fri, 21 Nov 2025 14:47:49 +0100 > Felix Moessbauer <[email protected]> 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 <[email protected]> > > --- > > Note, that this bug has been reported in [1]. > > > > [1] https://lore.kernel.org/linux-trace-devel/[email protected]/ > > > > 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