==5075== 333 bytes in 37 blocks are definitely lost in loss record 4,612 of 4,761
==5075== at 0x4C2CE5F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5075== by 0x66E3028: g_malloc (in /usr/lib/libglib-2.0.so.0.5200.3)
==5075== by 0x66CAD42: g_path_get_basename (in /usr/lib/libglib-2.0.so.0.5200.3)
==5075== by 0x20BE20: preload_driver (mm-kernel-device-generic.c:242)
==5075== by 0x20C8E5: preload_contents (mm-kernel-device-generic.c:391)
==5075== by 0x20E2E1: check_preload (mm-kernel-device-generic.c:830)
==5075== by 0x20EA6F: set_property (mm-kernel-device-generic.c:953)
==5075== by 0x6455359: ??? (in /usr/lib/libgobject-2.0.so.0.5200.3)
==5075== by 0x6456DBC: g_object_new_valist (in /usr/lib/libgobject-2.0.so.0.5200.3)
==5075== by 0x6105E95: g_initable_new_valist (in /usr/lib/libgio-2.0.so.0.5200.3)
==5075== by 0x6105F58: g_initable_new (in /usr/lib/libgio-2.0.so.0.5200.3)
==5075== by 0x20E848: mm_kernel_device_generic_new_with_rules (mm-kernel-device-generic.c:901)
Cancelling the port_context->cancellable may end up finishing the
async task and completing the last reference of the port
context. Avoid that by making sure we hold a valid reference for as
long as we may need it.
==2277== Invalid read of size 4
==2277== at 0x14ACE2: port_context_cancel (mm-plugin-manager.c:547)
==2277== by 0x14C32E: device_context_port_released (mm-plugin-manager.c:1142)
==2277== by 0x83831C7: ffi_call_unix64 (in /usr/lib/libffi.so.6.0.4)
==2277== by 0x8382C29: ffi_call (in /usr/lib/libffi.so.6.0.4)
==2277== by 0x64506A8: g_cclosure_marshal_generic (in /usr/lib/libgobject-2.0.so.0.5200.3)
==2277== by 0x644FEAC: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.5200.3)
==2277== by 0x64624AD: ??? (in /usr/lib/libgobject-2.0.so.0.5200.3)
==2277== by 0x646AC84: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.5200.3)
==2277== by 0x646B69E: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.5200.3)
==2277== by 0x1483E7: mm_device_release_port (mm-device.c:196)
==2277== by 0x145D5D: device_removed (mm-base-manager.c:217)
==2277== by 0x1464A9: handle_kernel_event (mm-base-manager.c:401)
==2277== Address 0xf677d18 is 88 bytes inside a block of size 96 free'd
==2277== at 0x4C2E14B: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==2277== by 0x14A1B7: port_context_unref (mm-plugin-manager.c:234)
==2277== by 0x14AB51: plugin_supports_port_ready (mm-plugin-manager.c:492)
==2277== by 0x612FD52: ??? (in /usr/lib/libgio-2.0.so.0.5200.3)
==2277== by 0x6130775: ??? (in /usr/lib/libgio-2.0.so.0.5200.3)
==2277== by 0x1AFDF8: port_probe_run_ready (mm-plugin.c:624)
==2277== by 0x612FD52: ??? (in /usr/lib/libgio-2.0.so.0.5200.3)
==2277== by 0x6130775: ??? (in /usr/lib/libgio-2.0.so.0.5200.3)
==2277== by 0x6131367: g_task_return_error_if_cancelled (in /usr/lib/libgio-2.0.so.0.5200.3)
==2277== by 0x1A9EDA: port_probe_task_return_error_if_cancelled (mm-port-probe.c:109)
==2277== by 0x1ABCD2: serial_probe_at_parse_response (mm-port-probe.c:900)
==2277== by 0x611E475: g_simple_async_result_complete (in /usr/lib/libgio-2.0.so.0.5200.3)
==2277== Block was alloc'd at
==2277== at 0x4C2CE5F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==2277== by 0x66E3028: g_malloc (in /usr/lib/libglib-2.0.so.0.5200.3)
==2277== by 0x66FAB25: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.5200.3)
==2277== by 0x66FAFB8: g_slice_alloc0 (in /usr/lib/libglib-2.0.so.0.5200.3)
==2277== by 0x14B18D: port_context_new (mm-plugin-manager.c:649)
==2277== by 0x14C4A7: device_context_port_grabbed (mm-plugin-manager.c:1182)
==2277== by 0x83831C7: ffi_call_unix64 (in /usr/lib/libffi.so.6.0.4)
==2277== by 0x8382C29: ffi_call (in /usr/lib/libffi.so.6.0.4)
==2277== by 0x64506A8: g_cclosure_marshal_generic (in /usr/lib/libgobject-2.0.so.0.5200.3)
==2277== by 0x644FEAC: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.5200.3)
==2277== by 0x64624AD: ??? (in /usr/lib/libgobject-2.0.so.0.5200.3)
==2277== by 0x646AC84: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.5200.3)
If the GCancellable is already cancelled when trying to connect a
signal, the callback given will be run right away, and that may end up
completing the async task and removing the last MMPortSerial
reference.
==30627== Invalid write of size 8
==30627== at 0x1ED43B: port_serial_queue_process (mm-port-serial.c:812)
==30627== by 0x66DE342: ??? (in /usr/lib/libglib-2.0.so.0.5200.3)
==30627== by 0x66DD8C4: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.5200.3)
==30627== by 0x66DDC87: ??? (in /usr/lib/libglib-2.0.so.0.5200.3)
==30627== by 0x66DDFA1: g_main_loop_run (in /usr/lib/libglib-2.0.so.0.5200.3)
==30627== by 0x143F9B: main (main.c:180)
==30627== Address 0xf6f0e98 is 200 bytes inside a block of size 328 free'd
==30627== at 0x4C2E14B: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==30627== by 0x64742B2: g_type_free_instance (in /usr/lib/libgobject-2.0.so.0.5200.3)
==30627== by 0x1ED0F2: port_serial_got_response (mm-port-serial.c:704)
==30627== by 0x1ED21B: port_serial_response_wait_cancelled (mm-port-serial.c:757)
==30627== by 0x60E1A81: g_cancellable_connect (in /usr/lib/libgio-2.0.so.0.5200.3)
==30627== by 0x1ED43A: port_serial_queue_process (mm-port-serial.c:812)
==30627== by 0x66DE342: ??? (in /usr/lib/libglib-2.0.so.0.5200.3)
==30627== by 0x66DD8C4: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.5200.3)
==30627== by 0x66DDC87: ??? (in /usr/lib/libglib-2.0.so.0.5200.3)
==30627== by 0x66DDFA1: g_main_loop_run (in /usr/lib/libglib-2.0.so.0.5200.3)
==30627== by 0x143F9B: main (main.c:180)
==30627== Block was alloc'd at
==30627== at 0x4C2CE5F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==30627== by 0x66E3028: g_malloc (in /usr/lib/libglib-2.0.so.0.5200.3)
==30627== by 0x66FAB25: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.5200.3)
==30627== by 0x66FAFB8: g_slice_alloc0 (in /usr/lib/libglib-2.0.so.0.5200.3)
==30627== by 0x6473FB5: g_type_create_instance (in /usr/lib/libgobject-2.0.so.0.5200.3)
==30627== by 0x6455027: ??? (in /usr/lib/libgobject-2.0.so.0.5200.3)
==30627== by 0x6456DBC: g_object_new_valist (in /usr/lib/libgobject-2.0.so.0.5200.3)
==30627== by 0x6457200: g_object_new (in /usr/lib/libgobject-2.0.so.0.5200.3)
==30627== by 0x1F253A: mm_port_serial_at_new (mm-port-serial-at.c:533)
==30627== by 0x1AC7E7: serial_open_at (mm-port-probe.c:1210)
==30627== by 0x66DD8C4: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.5200.3)
==30627== by 0x66DDC87: ??? (in /usr/lib/libglib-2.0.so.0.5200.3)
==28888== 622 (280 direct, 342 indirect) bytes in 7 blocks are definitely lost in loss record 2,515 of 2,548
==28888== at 0x6474014: g_type_create_instance (in /usr/lib/libgobject-2.0.so.0.5200.3)
==28888== by 0x6455027: ??? (in /usr/lib/libgobject-2.0.so.0.5200.3)
==28888== by 0x6456A54: g_object_newv (in /usr/lib/libgobject-2.0.so.0.5200.3)
==28888== by 0x6457213: g_object_new (in /usr/lib/libgobject-2.0.so.0.5200.3)
==28888== by 0x4E9DD7D: mm_kernel_event_properties_new (mm-kernel-event-properties.c:422)
==28888== by 0x4E9D8BC: mm_kernel_event_properties_new_from_string (mm-kernel-event-properties.c:283)
==28888== by 0x1465D7: process_initial_kernel_events (mm-base-manager.c:555)
==28888== by 0x14679E: mm_base_manager_start (mm-base-manager.c:581)
==28888== by 0x143CF3: name_acquired_cb (main.c:110)
==28888== by 0x616B805: ??? (in /usr/lib/libgio-2.0.so.0.5200.3)
==28888== by 0x616BA47: ??? (in /usr/lib/libgio-2.0.so.0.5200.3)
==28888== by 0x612FD52: ??? (in /usr/lib/libgio-2.0.so.0.5200.3)
We cannot in any way try to disconnect a GCancellable from within a
cancellation handler, or we'll deadlock.
Thread 1 (Thread 0x7fe98bf25700 (LWP 12079)):
#0 0x00007fe98a355f36 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#1 0x00007fe98a7f5ac0 in g_cond_wait () from /usr/lib/libglib-2.0.so.0
#2 0x00007fe98ad14650 in g_cancellable_disconnect () from /usr/lib/libgio-2.0.so.0
#3 0x000000000045be5d in port_probe_run_context_free ()
#4 0x00007fe98ad519ed in g_task_finalize () from /usr/lib/libgio-2.0.so.0
#5 0x00007fe98aaaa7b3 in g_object_unref () from /usr/lib/libgobject-2.0.so.0
#6 0x000000000045b5f8 in port_probe_task_return_error_if_cancelled ()
#7 0x000000000045c57d in serial_probe_at_parse_response ()
#8 0x00007fe98ad42ed2 in g_simple_async_result_complete () from /usr/lib/libgio-2.0.so.0
#9 0x0000000000485c7d in serial_command_ready ()
#10 0x00007fe98ad42ed2 in g_simple_async_result_complete () from /usr/lib/libgio-2.0.so.0
#11 0x0000000000482345 in command_context_complete_and_free ()
#12 0x0000000000482fa5 in port_serial_got_response ()
#13 0x00000000004830f5 in port_serial_response_wait_cancelled ()
#14 0x00007fe98aaa70c5 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#15 0x00007fe98aab47ce in signal_emit_unlocked_R () from /usr/lib/libgobject-2.0.so.0
#16 0x00007fe98aabb595 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#17 0x00007fe98aabb662 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#18 0x00007fe98ad144c5 in g_cancellable_cancel () from /usr/lib/libgio-2.0.so.0
#19 0x00007fe98aaa70c5 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#20 0x00007fe98aab47ce in signal_emit_unlocked_R () from /usr/lib/libgobject-2.0.so.0
#21 0x00007fe98aabb595 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#22 0x00007fe98aabb662 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#23 0x00007fe98ad144c5 in g_cancellable_cancel () from /usr/lib/libgio-2.0.so.0
#24 0x000000000042e9f6 in port_context_cancel ()
#25 0x00007fe989b99a4c in ffi_call_unix64 () at ../src/x86/unix64.S:75
#26 0x00007fe989b994b9 in ffi_call (cif=0x7fffc41dcdb0, fn=0x42ea40 <device_context_port_released>, rvalue=<optimized out>, avalue=0x7fffc41dccd0) at ../src/x86/ffi64.c:492
#27 0x00007fe98aaa7700 in g_cclosure_marshal_generic () from /usr/lib/libgobject-2.0.so.0
#28 0x00007fe98aaa70c5 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#29 0x00007fe98aab47ce in signal_emit_unlocked_R () from /usr/lib/libgobject-2.0.so.0
#30 0x00007fe98aabb595 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#31 0x00007fe98aabb662 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#32 0x000000000042c8f0 in mm_device_release_port ()
#33 0x000000000042a6cb in device_removed ()
#34 0x000000000042af94 in handle_kernel_event ()
#35 0x000000000042b356 in report_kernel_event_auth_ready ()
#36 0x00007fe98ad51783 in g_task_return_now () from /usr/lib/libgio-2.0.so.0
#37 0x00007fe98ad517b9 in complete_in_idle_cb () from /usr/lib/libgio-2.0.so.0
#38 0x00007fe98a7bda5e in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#39 0x00007fe98a7bddb8 in g_main_context_iterate.isra () from /usr/lib/libglib-2.0.so.0
#40 0x00007fe98a7be042 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#41 0x0000000000428dc4 in main ()
So, just clear the cancellation id before going on with the handler logic.
When the Ericsson F5321 with firmware R3C11/R4D04 is told to make
an IPv6-only connection, it reports that it has IPv4 configuration
but then returns no actual addresses. Check both the flags and
actual data before trying to use them.
ModemManager[25850]: <debug> [1506958721.914717] IPv4 configuration available: 'address, gateway, dns, mtu'
ModemManager[25850]: <debug> [1506958721.914731] IP addresses (0)
ModemManager[25850]: <debug> [1506958721.914741] DNS addresses (0)
ModemManager[25850]: <debug> [1506958721.914748] MTU: '0'
ModemManager[25850]: <debug> [1506958721.914758] IPv6 configuration available: 'address, dns, mtu'
ModemManager[25850]: <debug> [1506958721.914767] IP addresses (1)
ModemManager[25850]: <debug> [1506958721.914852] IP [0]: 'fe80::39:f622:7d01/64'
ModemManager[25850]: <debug> [1506958721.914866] DNS addresses (2)
ModemManager[25850]: <debug> [1506958721.914883] DNS [0]: 'fd00:976a::9'
ModemManager[25850]: <debug> [1506958721.914896] MTU: '1500'
ModemManager[25850]: <debug> [1506958721.914947] (wwp0s20u1i6): port now connected
The returned list contains full references, so make sure we unref them
before going on. Note that it's ok to return a pointer to one object
inside this list even if we're unref-ing them all, because we're sure
that the caller knows it's peek-ing a port object.
All the steps in the connect_3gpp() sequence are implemented as
methods in the MMBroadbandBearer class, and therefore the objects
received in the corresponding ready() methods are all bearers, not
modems.
This issue wasn't found before because the objects received were not
really being used after all, as we were relying on the ones kept in
the context or lately in the GTask itself.
This patch implements hardware revision loading in MMBroadbandModemMbim
by extracting the HardwareInfo field from the response to a
MBIM_CID_DEVICE_CAPS query.
