Fix use of g_variant_new_from_data()
When it’s done, it calls notify(user_data)
, not notify(data)
(as
documented). If user_data
is NULL
, this means data
is never freed;
if data
is newly allocated and not pointed to from elsewhere, that
means it’s leaked.
This was leading to leaks like the following in flatpak (actually seen via valgrinding gnome-software):
==367172== 4,354 bytes in 6 blocks are definitely lost in loss record 90,953 of 91,988
==367172== at 0x484486F: malloc (vg_replace_malloc.c:381)
==367172== by 0x4F76D09: g_malloc (gmem.c:125)
==367172== by 0x4FA0FED: g_memdup (gstrfuncs.c:392)
==367172== by 0x1B887BFF: var_metadata_dup_to_gvariant (flatpak-variant-impl-private.h:391)
==367172== by 0x1B88D731: try_resolve_op_from_metadata (flatpak-transaction.c:3160)
==367172== by 0x1B88DFC9: resolve_ops (flatpak-transaction.c:3332)
==367172== by 0x1B88E3A4: resolve_all_ops (flatpak-transaction.c:3397)
==367172== by 0x1B89241D: flatpak_transaction_real_run (flatpak-transaction.c:4791)
Unfortunately there’s one remaining use of g_variant_new_from_data()
,
in {prefix_}variant_to_gvariant()
which can’t be fixed as the user
provides the notify
and user_data
.
Signed-off-by: Philip Withnall pwithnall@endlessos.org
Edited by Philip Withnall