Memory leak when unref MMManager object

Aleksander Morgado aleksander at
Fri Mar 13 16:56:14 UTC 2020


> 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:


More information about the ModemManager-devel mailing list