Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix a bunch of memory leaks #58

Merged
merged 2 commits into from
Apr 26, 2024
Merged

Conversation

swick
Copy link
Contributor

@swick swick commented Apr 24, 2024

Based on a patch (#51 (comment)) by @spiiroin with an extra commit on top fixing a few more cases.

@swick swick force-pushed the mr/gvariant-leaks branch from cff8fd8 to 213ce62 Compare April 24, 2024 13:58
@matthiasclasen
Copy link
Contributor

Looks good to me, but we need to rebase this to get ci to pass

spiiroin and others added 2 commits April 26, 2024 13:03
There is memory leakage that is proportional to amount of incoming
dbus traffic. Analyzing valgrind logs points towards GVariant
reference leaks from functions like validate_arg0_name().

Documentation for g_variant_get_child_value() states: "The returned
value is never floating. You should free it with g_variant_unref()
when you're done with it." Many functions omit such cleanup actions.

Use g_autoptr(GVariant) type for variables that are used for storing
g_variant_get_child_value() return value - like how it is already done
in get_arg0_string().

Signed-off-by: Simo Piiroinen <simo.piiroinen@jolla.com>
This also fixes a few cases where the message is no unreffed if the
arguments are unexpected.

Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>
@GeorgesStavracas GeorgesStavracas merged commit 03bec4a into flatpak:main Apr 26, 2024
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants