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. > 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 -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|