[PATCH] perf data convert json: Fix trace_seq memory leak in process_sample_event()

[PATCH] perf data convert json: Fix trace_seq memory leak in process_sample_event()

[Tanushree Shah]

Unlike the in-kernel trace_seq which uses a statically allocated buffer,
the userspace traceevent library's trace_seq uses a dynamically allocated
one. Therefore, every trace_seq_init() call must be paired with a
trace_seq_destroy(), otherwise it produces a memory leak.

In process_sample_event(), a trace_seq is initialized for each field when
formatting tracepoint raw_data, but the matching trace_seq_destroy() is
never called, leaking memory for every field of every sample processed.

Add the missing trace_seq_destroy() after using the trace_seq buffer to
properly free the allocated memory.

Detected with Valgrind on a perf.data file with 2,729 tracepoint samples:
  Before: definitely lost: 55,537,664 bytes in 13,559 blocks
  After:  definitely lost: 0 bytes in 0 blocks

Fixes: 9d895e468429 ("perf data: Add tracepoint fields when converting to JSON")
Signed-off-by: Tanushree Shah <tshah@linux.ibm.com>
---
 tools/perf/util/data-convert-json.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/perf/util/data-convert-json.c b/tools/perf/util/data-convert-json.c
index d526c91312ed..6dd9349ab10f 100644
--- a/tools/perf/util/data-convert-json.c
+++ b/tools/perf/util/data-convert-json.c
@@ -257,6 +257,7 @@ static int process_sample_event(const struct perf_tool *tool,
 				trace_seq_init(&s);
 				tep_print_field(&s, sample->raw_data, fields[i]);
 				output_json_key_string(out, true, 3, fields[i]->name, s.buffer);
+				trace_seq_destroy(&s);
 
 				i++;
 			}
-- 
2.47.3

Re: [PATCH] perf data convert json: Fix trace_seq memory leak in process_sample_event()

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The `process_sample_event()` function leaks reference counts and memory associated with `struct addr_location` when a sample is skipped due to time filtering.
--

commit de6e4710063f2942dd58ebe436d7d992872132b3
Author: Tanushree Shah <tshah@linux.ibm.com>

perf data convert json: Fix trace_seq memory leak in process_sample_event()

This commit fixes a memory leak by ensuring trace_seq_destroy() is called
to pair with trace_seq_init() when formatting tracepoint raw data.

> diff --git a/tools/perf/util/data-convert-json.c b/tools/perf/util/data-convert-json.c
> index d526c91312ed8..6dd9349ab10f1 100644
> --- a/tools/perf/util/data-convert-json.c
> +++ b/tools/perf/util/data-convert-json.c
> @@ -257,6 +257,7 @@ static int process_sample_event(const struct perf_tool *tool,
>  				trace_seq_init(&s);
>  				tep_print_field(&s, sample->raw_data, fields[i]);
>  				output_json_key_string(out, true, 3, fields[i]->name, s.buffer);
> +				trace_seq_destroy(&s);
>  
>  				i++;
>  			}

[Severity: High]
This is a pre-existing issue, but does the early return path for skipped
samples higher up in process_sample_event() leak the addr_location
reference handles?

tools/perf/util/data-convert-json.c:process_sample_event() {
        addr_location__init(&al);
        if (machine__resolve(machine, &al, sample) < 0) {
                pr_err("Sample resolution failed!\n");
                addr_location__exit(&al);
                return -1;
        }

        if (perf_time__ranges_skip_sample(c->ptime_range, c->range_num, sample->time)) {
                ++c->skipped;
                return 0;
        }
        ...
}

When machine__resolve() populates the addr_location structure, it acquires
reference handles for objects like thread and map. The early return for time
filtering bypasses the addr_location__exit() cleanup.

Could this cause reference counts and memory to leak when dropping skipped
samples?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260604065519.112101-1-tshah@linux.ibm.com?part=1

Re: [PATCH] perf data convert json: Fix trace_seq memory leak in process_sample_event()

[Tanushree Shah]

Hi Sashiko,

Thank you for the review and for spotting this!

Regarding the addr_location reference leak:

yes its correct. The early return path for time-filtered samples does 
leak addr_location references.

When machine__resolve() succeeds, it calls thread__find_map(), which 
acquires reference counts for thread, map, and maps objects and stores 
them in the addr_location structure. The early return bypasses 
addr_location__exit(), preventing these references from being released.

Validation with Valgrind:

I've validated the issue with Valgrind using a test case with 2,385 
total samples (150 converted, 2,235 skipped by time filter):

Without the fix:

definitely lost:  8,336 bytes in 32 blocks
indirectly lost:  1,539,361 bytes in 21,307 blocks
possibly lost:    10,325,465 bytes in 146,283 blocks
Total leaked:     ~11.9 MB

With the fix:

definitely lost:  0 bytes in 0 blocks
indirectly lost:  0 bytes in 0 blocks
possibly lost:    0 bytes in 0 blocks
Total leaked:     0 bytes


I will send a v2 patch series that addresses both memory leaks:

The trace_seq_destroy() fix (original issue)
The addr_location__exit() fix for the early return path

Thanks
Tanushree Shah

On 04/06/26 12:36, sashiko-bot@kernel.org wrote:
> perf data convert json: Fix trace_seq memory leak in process_sample_event()
> 
> This commit fixes a memory leak by ensuring trace_seq_destroy() is called
> to pair with trace_seq_init() when formatting tracepoint raw data.
> 
>> diff --git a/tools/perf/util/data-convert-json.c b/tools/perf/util/data-convert-json.c
>> index d526c91312ed8..6dd9349ab10f1 100644
>> --- a/tools/perf/util/data-convert-json.c
>> +++ b/tools/perf/util/data-convert-json.c
>> @@ -257,6 +257,7 @@ static int process_sample_event(const struct perf_tool *tool,
>>   				trace_seq_init(&s);
>>   				tep_print_field(&s, sample->raw_data, fields[i]);
>>   				output_json_key_string(out, true, 3, fields[i]->name, s.buffer);
>> +				trace_seq_destroy(&s);
>>   
>>   				i++;
>>   			}
> [Severity: High]
> This is a pre-existing issue, but does the early return path for skipped
> samples higher up in process_sample_event() leak the addr_location
> reference handles?
> 
> tools/perf/util/data-convert-json.c:process_sample_event() {
>          addr_location__init(&al);
>          if (machine__resolve(machine, &al, sample) < 0) {
>                  pr_err("Sample resolution failed!\n");
>                  addr_location__exit(&al);
>                  return -1;
>          }
> 
>          if (perf_time__ranges_skip_sample(c->ptime_range, c->range_num, sample->time)) {
>                  ++c->skipped;
>                  return 0;
>          }
>          ...
> }
> 
> When machine__resolve() populates the addr_location structure, it acquires
> reference handles for objects like thread and map. The early return for time
> filtering bypasses the addr_location__exit() cleanup.
> 
> Could this cause reference counts and memory to leak when dropping skipped
> samples?
> 
> -- Sashiko AI review · https://sashiko.dev/#/ 
> patchset/20260604065519.112101-1-tshah@linux.ibm.com?part=1

Re: [PATCH] perf data convert json: Fix trace_seq memory leak in process_sample_event()

[Arnaldo Carvalho de Melo]

On Thu, Jun 04, 2026 at 12:25:19PM +0530, Tanushree Shah wrote:
> Unlike the in-kernel trace_seq which uses a statically allocated buffer,
> the userspace traceevent library's trace_seq uses a dynamically allocated
> one. Therefore, every trace_seq_init() call must be paired with a
> trace_seq_destroy(), otherwise it produces a memory leak.
> 
> In process_sample_event(), a trace_seq is initialized for each field when
> formatting tracepoint raw_data, but the matching trace_seq_destroy() is
> never called, leaking memory for every field of every sample processed.
> 
> Add the missing trace_seq_destroy() after using the trace_seq buffer to
> properly free the allocated memory.
> 
> Detected with Valgrind on a perf.data file with 2,729 tracepoint samples:
>   Before: definitely lost: 55,537,664 bytes in 13,559 blocks
>   After:  definitely lost: 0 bytes in 0 blocks

Thanks, applied to perf-tools-next, for v7.2.

- Arnaldo
 
> Fixes: 9d895e468429 ("perf data: Add tracepoint fields when converting to JSON")
> Signed-off-by: Tanushree Shah <tshah@linux.ibm.com>
> ---
>  tools/perf/util/data-convert-json.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tools/perf/util/data-convert-json.c b/tools/perf/util/data-convert-json.c
> index d526c91312ed..6dd9349ab10f 100644
> --- a/tools/perf/util/data-convert-json.c
> +++ b/tools/perf/util/data-convert-json.c
> @@ -257,6 +257,7 @@ static int process_sample_event(const struct perf_tool *tool,
>  				trace_seq_init(&s);
>  				tep_print_field(&s, sample->raw_data, fields[i]);
>  				output_json_key_string(out, true, 3, fields[i]->name, s.buffer);
> +				trace_seq_destroy(&s);
>  
>  				i++;
>  			}
> -- 
> 2.47.3

Re: [PATCH] perf data convert json: Fix trace_seq memory leak in process_sample_event()

[Tanushree Shah]

Hello Arnaldo

Thanks for checking the patch. I cannot see this patch applied on 
perf-tools-next yet.

https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/log/?h=perf-tools-next

Thanks.

On 05/06/26 02:59, Arnaldo Carvalho de Melo wrote:
> On Thu, Jun 04, 2026 at 12:25:19PM +0530, Tanushree Shah wrote:
>> Unlike the in-kernel trace_seq which uses a statically allocated buffer,
>> the userspace traceevent library's trace_seq uses a dynamically allocated
>> one. Therefore, every trace_seq_init() call must be paired with a
>> trace_seq_destroy(), otherwise it produces a memory leak.
>>
>> In process_sample_event(), a trace_seq is initialized for each field when
>> formatting tracepoint raw_data, but the matching trace_seq_destroy() is
>> never called, leaking memory for every field of every sample processed.
>>
>> Add the missing trace_seq_destroy() after using the trace_seq buffer to
>> properly free the allocated memory.
>>
>> Detected with Valgrind on a perf.data file with 2,729 tracepoint samples:
>>    Before: definitely lost: 55,537,664 bytes in 13,559 blocks
>>    After:  definitely lost: 0 bytes in 0 blocks
> 
> Thanks, applied to perf-tools-next, for v7.2.
> 
> - Arnaldo
>   
>> Fixes: 9d895e468429 ("perf data: Add tracepoint fields when converting to JSON")
>> Signed-off-by: Tanushree Shah <tshah@linux.ibm.com>
>> ---
>>   tools/perf/util/data-convert-json.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/tools/perf/util/data-convert-json.c b/tools/perf/util/data-convert-json.c
>> index d526c91312ed..6dd9349ab10f 100644
>> --- a/tools/perf/util/data-convert-json.c
>> +++ b/tools/perf/util/data-convert-json.c
>> @@ -257,6 +257,7 @@ static int process_sample_event(const struct perf_tool *tool,
>>   				trace_seq_init(&s);
>>   				tep_print_field(&s, sample->raw_data, fields[i]);
>>   				output_json_key_string(out, true, 3, fields[i]->name, s.buffer);
>> +				trace_seq_destroy(&s);
>>   
>>   				i++;
>>   			}
>> -- 
>> 2.47.3

Re: [PATCH] perf data convert json: Fix trace_seq memory leak in process_sample_event()

[Namhyung Kim]

Hello,

On Thu, Jun 11, 2026 at 05:23:45PM +0530, Tanushree Shah wrote:
> Hello Arnaldo
> 
> Thanks for checking the patch. I cannot see this patch applied on
> perf-tools-next yet.

According to the other comment, I guess you're supposed to send v2.  No?

Thanks,
Namhyung