On 13/06/2025 16:07, Daniel P. Berrangé wrote: > On Fri, Jun 13, 2025 at 12:40:02PM +0800, Li Zhijian via wrote: >> This leak was detected by the valgrind. >> >> The crs_range_merge() function unconditionally allocated a GPtrArray >> 'even when range->len was zero, causing an early return without freeing >> the allocated array. This resulted in a memory leak when an empty range >> was processed. >> >> Fix this by moving the GPtrArray allocation after the empty range check, >> ensuring memory is only allocated when actually needed. >> >> Signed-off-by: Li Zhijian <lizhij...@fujitsu.com> >> --- >> hw/acpi/aml-build.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c >> index f8f93a9f66c8..cf1999880119 100644 >> --- a/hw/acpi/aml-build.c >> +++ b/hw/acpi/aml-build.c >> @@ -160,7 +160,7 @@ void crs_replace_with_free_ranges(GPtrArray *ranges, >> */ >> static void crs_range_merge(GPtrArray *range) >> { >> - GPtrArray *tmp = g_ptr_array_new_with_free_func(crs_range_free); >> + GPtrArray *tmp; > > IMHO it would be better to change this to > > g_autoptr(GPtrArray) tmp = g_ptr.... > > > and remove the existing manual g_ptr_array_free call. This guarantees > it will always be released in every code path.
It sounds good to me, I will update it soon. Thank > >> CrsRangeEntry *entry; >> uint64_t range_base, range_limit; >> int i; >> @@ -169,6 +169,7 @@ static void crs_range_merge(GPtrArray *range) >> return; >> } >> >> + tmp = g_ptr_array_new_with_free_func(crs_range_free); >> g_ptr_array_sort(range, crs_range_compare); >> >> entry = g_ptr_array_index(range, 0); >> -- >> 2.47.0 >> >> > > With regards, > Daniel