==8663== 1 bytes in 1 blocks are definitely lost in loss record 5 of 4,864
==8663== at 0x4C2CEDF: malloc (vg_replace_malloc.c:299)
==8663== by 0x669FAC9: g_malloc (in /usr/lib/libglib-2.0.so.0.5600.1)
==8663== by 0x66B9AEA: g_strndup (in /usr/lib/libglib-2.0.so.0.5600.1)
==8663== by 0x66ACE52: g_match_info_fetch (in /usr/lib/libglib-2.0.so.0.5600.1)
==8663== by 0x4E96DD2: mm_location_gps_raw_add_trace (mm-location-gps-raw.c:208)
==8663== by 0x18721E: mm_iface_modem_location_gps_update (mm-iface-modem-location.c:264)
==8663== by 0x1B9C7F: loc_location_nmea_indication_cb (mm-shared-qmi.c:712)
==8663== by 0x640C9E7: g_cclosure_marshal_VOID__BOXEDv (in /usr/lib/libgobject-2.0.so.0.5600.1)
==8663== by 0x6409C95: ??? (in /usr/lib/libgobject-2.0.so.0.5600.1)
==8663== by 0x64259E8: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.5600.1)
==8663== by 0x642612F: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.5600.1)
==8663== by 0x54AAB2D: process_indication (qmi-loc.c:7454)
Reported by: Thomas Weißschuh <thomas@weissschuh.net>
ModemManager[18223]: <debug> [1530023432.028473] Modem has 3GPP capabilities, enabling the Modem 3GPP interface...
Thread 1 "ModemManager" received signal SIGSEGV, Segmentation fault.
0x0000555555618baa in common_enable_disable_unsolicited_events_signal_strength (task=0x5555558e4440) at mm-broadband-modem-qmi.c:6545
6545 if (ctx->enable)
(gdb) bt
#0 0x0000555555618baa in common_enable_disable_unsolicited_events_signal_strength (task=0x5555558e4440) at mm-broadband-modem-qmi.c:6545
#1 0x0000555555618d70 in common_enable_disable_unsolicited_events (self=0x55555597a3f0, enable=1, callback=0x5555555c8c20 <enable_unsolicited_events_ready>, user_data=0x5555559779b0)
at mm-broadband-modem-qmi.c:6719
#2 0x0000555555618e5b in modem_3gpp_enable_unsolicited_events (self=0x55555597a3f0, callback=0x5555555c8c20 <enable_unsolicited_events_ready>, user_data=0x5555559779b0) at mm-broadband-modem-qmi.c:6749
#3 0x00005555555c9095 in interface_enabling_step (task=0x5555559779b0) at mm-iface-modem-3gpp.c:1907
#4 0x00005555555c8c0a in setup_unsolicited_events_ready (self=0x55555597a3f0, res=0x5555558efad0, task=0x5555559779b0) at mm-iface-modem-3gpp.c:1795
#5 0x00007ffff681e204 in () at /usr/lib/libgio-2.0.so.0
#6 0x00007ffff681e239 in () at /usr/lib/libgio-2.0.so.0
#7 0x00007ffff62731d6 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
#8 0x00007ffff62735b1 in () at /usr/lib/libglib-2.0.so.0
#9 0x00007ffff62738e2 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#10 0x000055555559182c in main (argc=2, argv=0x7fffffffe4a8) at main.c:181
Fixes: baefe53ab9
After the tty is opened, the fd is passed off to a GIOChannel which
manages it. When the serial port is closed with _close_internal(),
g_io_channel_shutdown() is called which then calls g_io_unix_close() which
in turn close()s the fd.
_close_internal() performs a second explicit close() after the
g_io_channel_shutdown() which *in the best case scenario* will fail with
EBADF.
This is a race condition that can result in other file descriptors being
closed.
This change avoids double closing the serial port fd -- the shutdown() call
is removed in favour of the explicit close().
GVfs' libgvfsdbus.so GIo module, when automatically loaded, attempts to
discover if there's a session D-Bus instance to use. It tries real hard
to get the socket name it would use -- in absence of XDG_RUNTIME_DIR it
decides to make it up with user's home directory. When HOME is unset
too, it just tries to figure it out by looking into /etc/passwd. Which
upsets SELinux that would better not see us looking into it.
We trigger the load of the GIo modules, by using the GFile API to access
the the ports in /dev. They're utterly uesless to us, but there doesn't
seem to be a way to disable their load. Oh well.
For now, let's just ensure HOME is set and the problematic path in glib
is not taken.
Commit 2a97e39cdd in libmim ("libmbim-glib: add additional cause codes
to MbimNwError") added additional cause codes to MbimNwError. This
patch maps some of those MbimNwError to MMMobileEquipmentError.
This patch requires libmbim >= 1.17.1
assure_qmi_client() was created to help migrating MMBroadbandModemQmi code
to use GTask. Now that all MMBroadbandModemQmi code has been migrated to
use GTask, this patch removes the old ensure_qmi_client() and rename
assure_qmi_client() as ensure_qmi_client().