Skip to content
  • Thomas Haller's avatar
    libnm: fix crash creating checkpoint during find_checkpoint_info() · 6f85d3e0
    Thomas Haller authored
    Now that the D-Bus signals in server are reordered, creating
    a checkpoint in libnm crashes:
    
      $ examples/python/gi/checkpoint.py create 4
    
        #0  0x00007ffff6d011ee in __strcmp_sse2_unaligned () at /lib64/libc.so.6
        #1  0x00007fffeb611c90 in find_checkpoint_info (manager=manager@entry=0x5555559e5110 [NMManager], path=0x7fffdc0092f0 "/org/freedesktop/NetworkManager/Checkpoint/6")
            at libnm/nm-manager.c:153
        #2  0x00007fffeb611d8f in checkpoint_added (manager=0x5555559e5110 [NMManager], checkpoint=checkpoint@entry=0x555555a122d0 [NMCheckpoint]) at libnm/nm-manager.c:1194
        #3  0x00007fffef7db929 in g_cclosure_marshal_VOID__OBJECTv (closure=0x5555559e4b30, return_value=<optimized out>, instance=<optimized out>, args=<optimized out>, marshal_data=<optimized out>, n_params=<optimized out>, param_types=0x5555559e2fc0) at gmarshal.c:2102
        #4  0x00007fffef7d8976 in _g_closure_invoke_va (closure=0x5555559e4b30, return_value=0x0, instance=0x5555559e5110, args=0x7fffffffc1c8, n_params=1, param_types=0x5555559e2fc0)
            at gclosure.c:867
        #5  0x00007fffef7f3ff4 in g_signal_emit_valist (instance=instance@entry=0x5555559e5110, signal_id=signal_id@entry=97, detail=0, var_args=var_args@entry=0x7fffffffc1c8) at gsignal.c:3300
        #6  0x00007fffef7f4b48 in g_signal_emit_by_name (instance=instance@entry=0x5555559e5110, detailed_signal=detailed_signal@entry=0x7fffffffc310 "checkpoint-added") at gsignal.c:3487
        #7  0x00007fffeb6156d1 in deferred_notify_cb (data=0x5555559e5110) at libnm/nm-object.c:219
        #8  0x00007fffeb615ae7 in object_property_maybe_complete (self=0x5555559e5110 [NMManager]) at libnm/nm-object.c:555
        #9  0x00007fffeb615e5d in object_created (obj=<optimized out>, path=<optimized out>, user_data=<optimized out>) at libnm/nm-object.c:576
        #10 0x00007fffeb61648b in handle_object_array_property (pi=<optimized out>, value=0x7fffdc075070, property_name=0x7fffeb67f117 "checkpoints", self=0x5555559e5110 [NMManager])
            at libnm/nm-object.c:671
        #11 0x00007fffeb61648b in handle_property_changed (self=self@entry=0x5555559e5110 [NMManager], dbus_name=<optimized out>, value=<optimized out>) at libnm/nm-object.c:740
        #12 0x00007fffeb6166e9 in properties_changed (proxy=<optimized out>, changed_properties=<optimized out>, invalidated_properties=<optimized out>, user_data=0x5555559e5110)
            at libnm/nm-object.c:772
        ...
    
    That is, because NetworkManager now first emits signals that the checkpoint
    object was created, before answering the D-Bus request. That makes more
    sense, but leads to this crash.
    
    The ugliness of how libnm handles object visibility is considerable.
    libnm hides objects until they are fully initialized. So, when
    the async create-checkpoint operation returns, the object might not
    yet be ready to be exposed. We need to delay the result. It would be
    better if the API would simply return the created path.
    6f85d3e0