High memory usage by ModemManager

Geert Lens g.lens at livetech-systems.com
Fri Jan 10 11:01:26 UTC 2020


After figuring out how to get ModemManager and libglib2 to compile with debug symbols (Never do it in combination with Buildroot), we found that, when we enabled GPS using:

> mmcli -m 0 —location-enable-gps-nmea
> mmcli -m 0 —location-enable-gps-raw
> mmcli -m 0 —location-set-enable-signal
> mmcli -m 0 —location-set-gps-refresh-rate=0

a significant memory leak starts to appear, about 128 kB in 10 min runtime. This starts somewhere during the part where ModemManager is receiving the NMEA lines via the QMI and after that tries to parse them. See below for a snippet of the valgrind log:

==5713== 279 bytes in 7 blocks are possibly lost in loss record 1,174 of 1,184
==5713==    at 0x4847EB4: malloc (in /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)
==5713== 
==5713== 480 bytes in 4 blocks are possibly lost in loss record 1,175 of 1,184
==5713==    at 0x484AB84: realloc (in /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)
==5713== 
==5713== 1,032 bytes in 18 blocks are possibly lost in loss record 1,176 of 1,184
==5713==    at 0x484A904: calloc (in /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)
==5713== 
==5713== 1,267 bytes in 6 blocks are indirectly lost in loss record 1,177 of 1,184
==5713==    at 0x484AB84: realloc (in /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)
==5713== 
==5713== 2,393 bytes in 102 blocks are indirectly lost in loss record 1,178 of 1,184
==5713==    at 0x4847EB4: malloc (in /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)
==5713== 
==5713== 4,046 (24 direct, 4,022 indirect) bytes in 1 blocks are definitely lost in loss record 1,179 of 1,184
==5713==    at 0x4E36C24: g_type_create_instance (gtype.c:1844)
==5713==    by 0x4E139B3: g_object_new_internal (gobject.c:1799)
==5713==    by 0x4E158C3: g_object_new_valist (gobject.c:2122)
==5713==    by 0x4E15C7F: g_object_new (gobject.c:1642)
==5713==    by 0xE1F9B: mm_port_qmi_new (mm-port-qmi.c:615)
==5713==    by 0x620AB: mm_base_modem_grab_port (mm-base-modem.c:295)
==5713==    by 0xA665F: mm_plugin_create_modem (mm-plugin.c:1048)
==5713==    by 0x507FF: mm_device_create_modem (mm-device.c:411)
==5713==    by 0x4D44B: device_support_check_ready (mm-base-manager.c:195)
==5713==    by 0x4D2029F: g_task_return_now (gtask.c:1148)
==5713==    by 0x4D20F27: g_task_return (gtask.c:1206)
==5713==    by 0x4D214AF: g_task_return_pointer (gtask.c:1604)
==5713== 
==5713== 7,180 bytes in 340 blocks are still reachable in loss record 1,180 of 1,184
==5713==    at 0x4847DC8: malloc (in /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)
==5713== 
==5713== 42,766 bytes in 232 blocks are still reachable in loss record 1,181 of 1,184
==5713==    at 0x484AB84: realloc (in /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)
==5713== 
==5713== 81,777 bytes in 2,312 blocks are still reachable in loss record 1,182 of 1,184
==5713==    at 0x4847EB4: malloc (in /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)
==5713== 
==5713== 101,244 bytes in 1,709 blocks are still reachable in loss record 1,183 of 1,184
==5713==    at 0x484A904: calloc (in /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)
==5713== 
==5713== 128,358 (128,324 direct, 34 indirect) bytes in 4,583 blocks are definitely lost in loss record 1,184 of 1,184
==5713==    at 0x4847EB4: malloc (in /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)
==5713== 
==5713== LEAK SUMMARY:
==5713==    definitely lost: 128,348 bytes in 4,584 blocks
==5713==    indirectly lost: 4,056 bytes in 120 blocks
==5713==      possibly lost: 1,823 bytes in 33 blocks
==5713==    still reachable: 277,019 bytes in 5,789 blocks
==5713==                       of which reachable via heuristic:
==5713==                         newarray           : 5,736 bytes in 164 blocks
==5713==         suppressed: 0 bytes in 0 blocks
==5713== 
==5713== For lists of detected and suppressed errors, rerun with: -s
==5713== ERROR SUMMARY: 6 errors from 6 contexts (suppressed: 0 from 0)


It almost looks like the QMI messages, containing NMEA lines, are being stored in memory but never released. With this, we think that the leak is somewhere in the libmm-glib libraries, but we are not able to give you a good stack trace of that, because we are not able to compile the libmm-glib libraries with debug symbols. 
This is an issue on our side with Buildroot and it’s way of building packages.

Hopefully this information is useful,

Currently used versions:
ModemManager: v1.12.2
libqmi: v1.24.0
libglib2: v2.56

Geert Lens

> On 9 Jan 2020, at 15:25, Aleksander Morgado <aleksander at aleksander.es> wrote:
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20200110/6636270d/attachment.htm>


More information about the ModemManager-devel mailing list