Skip to content

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

Merge request reports