d99169022eefe658e405051ef58c1af6c653faee

When the modem gets unplugged, or system gone into suspend, we start losing the modem ports one by one. When the last is lost, we trigger the disposal of the modem (we call g_object_run_dispose() and then we call the main-reference unref()). So, if we end up losing all ports while the connection sequence was being run, we would end up in this situation, where we try to disconnect the bearers (the bearer and modem objects are still valid, as we have references around, but the list of bearers won't be available any more in the modem object as it was cleared in the modem dispose(). Thread 0 *CRASHED* ( SIGSEGV @ 0x00000000 ) 0x7f5cdbd5cda0 [ModemManager] - mm-bearer-list.c:163] mm_bearer_list_foreach 0x7f5cdbd6a4bd [ModemManager] - mm-iface-modem.c:110] bearer_status_changed 0x7f5cdbad0903 [libgobject-2.0.so.0.3000.2] - gclosure.c:774] g_closure_invoke 0x7f5cdbae1dbb [libgobject-2.0.so.0.3000.2] - gsignal.c:3272] signal_emit_unlocked_R 0x7f5cdbaeac82 [libgobject-2.0.so.0.3000.2] - gsignal.c:3003] g_signal_emit_valist 0x7f5cdbaeae5e [libgobject-2.0.so.0.3000.2] - gsignal.c:3060] g_signal_emit 0x7f5cdbad3876 [libgobject-2.0.so.0.3000.2] - gobject.c:925] g_object_dispatch_properties_changed 0x7f5cdbad5ceb [libgobject-2.0.so.0.3000.2] - gobjectnotifyqueue.c:132] g_object_notify_by_pspec 0x7f5cdbd56b08 [ModemManager] - mm-bearer.c:112] bearer_update_status 0x7f5cdbd56ffd [ModemManager] - mm-bearer.c:393] disconnect_ready 0x7f5cdbbcc676 [libgio-2.0.so.0.3000.2] - gsimpleasyncresult.c:749] g_simple_async_result_complete 0x7f5cdbbcc788 [libgio-2.0.so.0.3000.2] - gsimpleasyncresult.c:761] complete_in_idle_cb 0x7f5cdb7cff44 [libglib-2.0.so.0.3000.2] - gmain.c:2441] g_main_context_dispatch 0x7f5cdb7d0597 [libglib-2.0.so.0.3000.2] - gmain.c:3089] g_main_context_iterate 0x7f5cdb7d0b51 [libglib-2.0.so.0.3000.2] - gmain.c:3297] g_main_loop_run 0x7f5cdbd4e331 [ModemManager] - main.c:150] main 0x7f5cdb1ea41c [libc-2.15.so] - libc-start.c:234] __libc_start_main 0x7f5cdbd4de48 [ModemManager] + 0x00019e48] Reported by Ben Chan <benchan@google.com>
license: use GPLv2 as top level COPYING for now to reflect the license actually used by source files
ModemManager. The problem ModemManager tries to solve is to provide a unified high level API for communicating with (mobile broadband) modems. While the basic commands are standardized, the more advanced operations (like signal quality monitoring while connected) varies a lot. Using. ModemManager is a system daemon and is not meant to be used directly from the command line. However, since it provides DBus API, it is possible to use 'dbus-send' command to control it from the terminal. There's an example program (tests/mm-test.py) that demonstrates the basic API usage. Implementation. ModemManager is a DBus system bus activated service (meaning it's started automatically when a request arrives). It is written in C. The devices are queried from udev and automatically updated based on hardware events. There's a GInterface (MMModem) that defines the modem interface and any device specific implementation must implement it. There are two generic MMModem implementations to support the basic operations (one for GSM, one for CDMA,) which are common for all cards. Plugins. Plugins are loaded on startup, and must implement the MMPlugin interface. It consists of a couple of methods which tell the daemon whether the plugin supports a port and to create custom MMModem implementations. It most likely makes sense to derive custom modem implementations from one of the generic classes and just add (or override) operations which are not standard. There's a fully working plugin in the plugins/ directory for Huawei cards that can be used as an example for writing new plugins. Writing new plugins is highly encouraged! API. The API is open for changes, so if you're writing a plugin and need to add or change some public method, feel free to suggest it!
Description
Languages
C
98.6%
Meson
0.8%
Python
0.4%
Shell
0.1%