* [PATCH] libtrace: Fix memory leak in tracefs_cpu
@ 2025-03-17 11:24 Kutzer, Philipp
2025-04-03 19:14 ` Steven Rostedt
0 siblings, 1 reply; 2+ messages in thread
From: Kutzer, Philipp @ 2025-03-17 11:24 UTC (permalink / raw)
To: linux-trace-devel@vger.kernel.org
From: Philipp Kutzer <philipp.kutzer@siemens-healthineers.com>
Hi,
with the introduction of the interface to allow the tracefs_cpu to handle buffer allocation on their
own a memory leak was built in.
(Commit 1e1cc549d7e7fa408081e03e4effd3591a131ae5 - libtracefs: Add API to read tracefs_cpu
and return a kbuffer)
We cyclically call the tracefs_iterate_raw_events function from one of our applications and
noticed that our application was increasingly allocating memory.
With the help of Address Sanitizer the root cause, allocating but not freeing memory
for "tcpu->buffer" was found. The fix will free memory during close and cleanup function
and has been successfully tested in our environment. The original problem (memory leak)
has been resolved.
Signed-off-by: Philipp Kutzer mailto:philipp.kutzer@siemens-healthineers.com
---
diff --git a/src/tracefs-record.c b/src/tracefs-record.c
index a2dcfc2..4cd0917 100644
--- a/src/tracefs-record.c
+++ b/src/tracefs-record.c
@@ -293,6 +293,8 @@ void tracefs_cpu_close(struct tracefs_cpu *tcpu)
if (!tcpu)
return;
+ free(tcpu->buffer);
+ tcpu->buffer = NULL;
close(tcpu->fd);
tracefs_cpu_free_fd(tcpu);
}
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH] libtrace: Fix memory leak in tracefs_cpu
2025-03-17 11:24 [PATCH] libtrace: Fix memory leak in tracefs_cpu Kutzer, Philipp
@ 2025-04-03 19:14 ` Steven Rostedt
0 siblings, 0 replies; 2+ messages in thread
From: Steven Rostedt @ 2025-04-03 19:14 UTC (permalink / raw)
To: Kutzer, Philipp; +Cc: linux-trace-devel@vger.kernel.org
On Mon, 17 Mar 2025 11:24:36 +0000
"Kutzer, Philipp" <philipp.kutzer@siemens-healthineers.com> wrote:
> From: Philipp Kutzer <philipp.kutzer@siemens-healthineers.com>
>
> Hi,
>
> with the introduction of the interface to allow the tracefs_cpu to handle buffer allocation on their
> own a memory leak was built in.
> (Commit 1e1cc549d7e7fa408081e03e4effd3591a131ae5 - libtracefs: Add API to read tracefs_cpu
> and return a kbuffer)
>
> We cyclically call the tracefs_iterate_raw_events function from one of our applications and
> noticed that our application was increasingly allocating memory.
>
> With the help of Address Sanitizer the root cause, allocating but not freeing memory
> for "tcpu->buffer" was found. The fix will free memory during close and cleanup function
> and has been successfully tested in our environment. The original problem (memory leak)
> has been resolved.
Note, I cleaned up the change log:
libtrace: Fix memory leak in tracefs_cpu
The introduction of the interface to allow the tracefs_cpu to handle buffer
allocation on their own caused a memory leak. (Commit 1e1cc549d7
("libtracefs: Add API to read tracefs_cpu and return a kbuffer")).
The help of Address Sanitizer found the root cause. The "tcpu->buffer" was
being allocated but not freed. The fix will free memory during close and
cleanup functions.
>
> Signed-off-by: Philipp Kutzer mailto:philipp.kutzer@siemens-healthineers.com
Also, this should be:
Signed-off-by: Philipp Kutzer <philipp.kutzer@siemens-healthineers.com>
> ---
>
> diff --git a/src/tracefs-record.c b/src/tracefs-record.c
> index a2dcfc2..4cd0917 100644
> --- a/src/tracefs-record.c
> +++ b/src/tracefs-record.c
> @@ -293,6 +293,8 @@ void tracefs_cpu_close(struct tracefs_cpu *tcpu)
> if (!tcpu)
> return;
>
> + free(tcpu->buffer);
> + tcpu->buffer = NULL;
> close(tcpu->fd);
> tracefs_cpu_free_fd(tcpu);
> }
This also had whitespace issues.
I fixed it up and applied it.
Thanks,
-- Steve
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2025-04-03 19:12 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-03-17 11:24 [PATCH] libtrace: Fix memory leak in tracefs_cpu Kutzer, Philipp
2025-04-03 19:14 ` Steven Rostedt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).