Memory leak when unref MMManager object

[Aleksander Morgado]

Hey Adrien,

> > There are no "memory leaks" per se; instead, there is memory that is
> > allocated but it is still reachable at program exit. The blocks
> > reported above are due to idle sources scheduled in the default
> > GMainContext, looks like there is some "cleanup in idle" logic
> > happening in the GDBusConnection object. That allocated memory is
> > triggered by creating the MMManager, and once the manager is unref-ed,
> > one "cleanup in idle" action is queued in the GDBusConnection,
> > something like that. So if you create 100 MMManagers and unref them
> > right away, all of those will end up scheduling the "cleanup in idle"
> > actions in the GDBusConnection.
> >
> > I assume your program doesn't have a GMainLoop? I'm not totally sure
> > why those cleanups are scheduled in idle (instead of just running the
> > cleanup without scheduling anything), I'd need to dig in the GLib
> > code. I did a quick hack just setting up a quick main loop with 1s
> > timeout before exit (see attached), and all that memory gets correctly
> > freed before exit. Not saying you should do that, that was just a test
> > to validate assumptions.
> >
> > Just using the "sync" APIs in libmm-glib and creating multiple
> > MMManager objects just to dispose them should be a supported thing,
> > but why is your program creating multiple MMManager objects anyway?
> > Maybe we can find another way to solve this issue if you're not
> > planning in setting up a GLib main loop in your code.
> >
>
> I've opened this issue in GLib to see what maintainers say:
> https://gitlab.gnome.org/GNOME/glib/issues/2066
>

The GLib maintainers replied to that bugreport with very detailed
information on why they idle cleanups are happening inside the GDBus
code. From the point of view of ModemManager, this means that we
should suggest having a GLib main loop running if you plan to have a
long-running program, because that is the way you ensure the lifecycle
of the DBus connection and client is managed and cleaned up properly.
For short-running programs, like e.g. mmcli, this requirement is
really avoidable, as the memory allocated but not yet freed will
anyway be freed once the process exits. And for your specific use case
(not sure if that was just a tester or part of a larger program), you
should definitely avoid creating multiple MMManager objects; just
create one and make sure it lives for as long it needs to live.

-- 
Aleksander
https://aleksander.es