Memory leak in g_dbus_proxy_new_for_bus_sync()

[Seyeong Kim]

[Impact]

This issue is found while debugging pacemaker lrmd memory leak

glib2.0 gio function g_dbus_proxy_new_for_bus_sync has leak as [1] said

this is affected to Trusty

[Test Case]

https://pastebin.ubuntu.com/p/fqK6Cx3SKK/
you can check memory leak with this script

[Regression]
This patch is affected to library pkg. so related daemon should be restarted after patching. patch itself is very simple and old. it seems verified for few years.

[Others]

original commit

https://gitlab.gnome.org/GNOME/glib/commit/db641e32920ee8b553ab6f2d318aafa156e4390c

[Dan Streetman (ddstreet)]

Seyeong, the debdiff patch is very large, and contains more than just the 1-line memleak fix from the description...can you remove the extra changes from the debdiff so it only contains the memleak patch? Or explain why the other changes are needed?

[Seyeong Kim (seyeongkim)]

Hello ddstreet

yep, it is tricky..

In the beginning, I added only one line but build failed.

3 commits for building, only one line is related to memroy leak directly.

I retried it and attaching build link on lp

Thanks

https://launchpad.net/~xtrusia/+archive/ubuntu/sf160627-glib/+build/14383194/+files/buildlog_ubuntu-trusty-amd64.glib2.0_2.40.2-0ubuntu1+sf160627v20180222.0_BUILDING.txt.gz

[Dan Streetman (ddstreet)]

Seyeong,

+ - d/p/0001-GDBusProxy-Fix-a-memory-leak-during-initialization.patch

this fixes a memory leak, but in later code than the Trusty glib2.0 code

+ - d/p/0001-tests-gdatetime-Use-a-real-rather-than-invented-time.patch

this fixes an autopkgtest regression, that's unrelated to this memleak bug - it's ok to include in the same upload, but it needs its own lp bug. This is also needed in xenial glib2.0.

+ - d/p/0001-gio-Add-names-to-idles-and-timeouts.patch
+ - d/p/0002-gio-belatedly-port-gdbus-from-GSimpleAsyncResult-to-.patch

these patches are huge backports, that update the glib2.0 code to use a different function that appears to *introduce* the memleak that your first patch "fixes". Are you sure there is actually a memleak in the Trusty glib2.0 code? If so, it does not seem to be the one that your first patch fixes. In any case, this huge backport is not acceptable as a SRU for only a memleak.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Seyeong Kim (seyeongkim)]

@ddstreet

After analyzing code.

I don't think this fix is possible without any big changes for trusty.

and glib2.0 affects many pkgs it seems.

it is quite dangerous to fix this with large commits.

so lets focus on pacemaker instead of glib2.0

how about this ddstreet?

Thanks

[Dan Streetman (ddstreet)]

> so lets focus on pacemaker instead of glib2.0

sounds good - i will mark this as 'wont fix', but we can come back to it if needed.

Also note, the existing bug 1545308 appears to be the same as this.