The signal "notify:g-name-owner" is only emitted for well-known
names, but not for unique connection names (":1.x") such as the secret
agent's connection. Also, it will not be emited for private connections.
That meant that when the client disconnected without explicitly
unregistering, the NMSecretAgent was not cleaned up and leaked
indefinitely.
As only one instance of secret agent with a certain 'identifier/uid'
pair can register, this bug also prevented the client from registering
until restart of NetworkManager.
Fixes: df6706813a
This code was unused, because we never enqueued any hashes
to the @asked list. Note that hashing also might give wrong
hash collisions, so this was buggy anyway.
Also, note that impl_agent_manager_register_with_capabilities()
already ensures that duplicate agents are not registered
in the first place (find_agent_by_identifier_and_uid()).
Refactor the handling of the asynchronous requests so that now
NMSecretAgent has the following properties:
- The callback will *always* be invoked exactly once (sans crashes).
Even if you cancel the call or if you dispose NMSecretAgent with
pending calls. That allows the caller to rely on being called back
and possibly cleanup the user-data.
- Callbacks are always invoked asynchronously with respect to their
start-call.
- You can cancel all 3 types of operations, not only the 'GetSecrets'
call. Note that this will still not cancel the calls 'DeleteSecrets'
and 'SaveSecrets' on a D-Bus level.
When cancelling, the callback will be invoked synchronously with
respect to the cancel call, with an GError indicating the cancellation
(G_IO_ERROR_CANCELLED).
- During dispose, the callback is also invoked synchronously, with
some other error reason.
This also fixes a crash where handling of the asynchronous data was
messed up and the priv->requests hash would end up to containing dangling
pointers.
https://bugzilla.redhat.com/show_bug.cgi?id=1253407
The @dbus_owner field was only cleaned up when the
proxy disconnected and leaked otherwise.
Also, don't clear @dbus_owner together with the proxy.
Otherwise, get_description() might yield different results
after the proxy got cleared. That can lead to problems because
NMAgentManager tracks the secrets agents by their "dbus-owner" --
IOW, NMAgentManager uses the "dbus-owner" as identifer for the
secret agent. Thus it must not change.
Fixes: 2a2fd1216b
prop_filter() gets invoked on another thread and we don't take
a strong reference to the manager when subscribing the filter.
Fix the race, by passing on a weak reference.
It can happen on a regular basis when many events get raised.
It is probalby not avoidable and most likely not an issue, so
downgrade the warning to info level.
The logging macros _LOGD(), etc. are specific to each
file as they format the message according to their context.
Still, they were cumbersome to define and their implementation
was repeated over and over (slightly different at times).
Move the declaration of these macros to "nm-logging.h".
The source file now only needs to define _NMLOG(), and either
_NMLOG_ENABLED() or _NMLOG_DOMAIN.
This reduces code duplication and encourages a common implementation
and usage of these macros.
Don't clear NMDevice @master in nm_device_cleanup() if the device link
is still enslaved because this causes an inconsistent state in which
the slave in included in the @slaves field of master device but
@master of slave device is NULL.
In such state, if the master link gets deleted, NM receives a change
event for each slave and a deletion event for the master; the change
events should also remove slaves from @slaves of master device, but
since their @master field is NULL the removal can't be performed.
Later, when the master deletion event is received, @slaves is not empty
in dispose() of NMDevice and the following assertion is triggered:
dispose: runtime check failed: (priv->slaves == NULL)
https://bugzilla.redhat.com/show_bug.cgi?id=1243371
Program received signal SIGSEGV, Segmentation fault.
g_type_check_instance_cast (type_instance=type_instance@entry=0x89f180, iface_type=9004512) at gtype.c:4060
4060 node = lookup_type_node_I (type_instance->g_class->g_type);
(gdb) bt
#0 0x00007ffff4b44e80 in g_type_check_instance_cast (type_instance=type_instance@entry=0x89f180, iface_type=9004512) at gtype.c:4060
#1 0x000000000056a460 in connection_visibility_changed (connection=0x89f680 [NMKeyfileConnection], pspec=<optimized out>, user_data=0x89f180) at settings/nm-settings.c:870
#5 0x00007ffff4b3b54f in <emit signal notify:visible on instance 0x89f680 [NMKeyfileConnection]> (instance=instance@entry=0x89f680, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3393
#2 0x00007ffff4b200b5 in g_closure_invoke (closure=0x9131a0, return_value=return_value@entry=0x0, n_param_values=2, param_values=param_values@entry=0x7fffffffd540, invocation_hint=invocation_hint@entry=0x7fffffffd4c0) at gclosure.c:801
#3 0x00007ffff4b32499 in signal_emit_unlocked_R (node=node@entry=0x8696b0, detail=detail@entry=641, instance=instance@entry=0x89f680, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffd540) at gsignal.c:3581
#4 0x00007ffff4b3b1a0 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffd710) at gsignal.c:3337
#6 0x00007ffff4b24665 in g_object_dispatch_properties_changed (object=0x89f680 [NMKeyfileConnection], n_pspecs=<optimized out>, pspecs=<optimized out>) at gobject.c:1056
#7 0x00007ffff4b26d11 in g_object_notify (pspec=0x8ce660 [GParamBoolean], object=0x89f680 [NMKeyfileConnection]) at gobject.c:1149
#8 0x00007ffff4b26d11 in g_object_notify (object=0x89f680 [NMKeyfileConnection], property_name=property_name@entry=0x5d2eb9 "visible") at gobject.c:1197
#9 0x0000000000497f85 in set_visible (self=self@entry=0x89f680 [NMKeyfileConnection], new_visible=new_visible@entry=0) at settings/nm-settings-connection.c:296
#10 0x0000000000498165 in dispose (object=0x89f680 [NMKeyfileConnection]) at settings/nm-settings-connection.c:2390
#11 0x00007ffff4b24fec in g_object_unref (_object=0x89f680) at gobject.c:3137
#12 0x00000000004a4a4f in dispose (object=0xa24260 [NMVpnConnection]) at nm-active-connection.c:904
#13 0x00007ffff4b24fec in g_object_unref (_object=0xa24260) at gobject.c:3137
#14 0x0000000000577636 in nm_vpn_service_stop_connections (service=0x8ff610 [NMVpnService], quitting=1, reason=NM_VPN_CONNECTION_STATE_REASON_SERVICE_STOPPED) at vpn-manager/nm-vpn-service.c:150
#15 0x0000000000576ea2 in dispose (object=0x921060 [NMVpnManager]) at vpn-manager/nm-vpn-manager.c:284
#16 0x00007ffff4b24fec in g_object_unref (_object=0x921060) at gobject.c:3137
#17 0x00000000004d0f05 in dispose (object=0x88a2b0 [NMManager]) at nm-manager.c:5061
#18 0x00007ffff4b24fec in g_object_unref (_object=0x88a2b0) at gobject.c:3137
#19 0x0000000000444e08 in _nm_singleton_instance_destroy () at NetworkManagerUtils.c:138
#20 0x00007ffff7de97b7 in _dl_fini () at dl-fini.c:252
#21 0x00007ffff4444778 in __run_exit_handlers (status=status@entry=0, listp=0x7ffff47d0618 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true) at exit.c:82
#22 0x00007ffff44447c5 in __GI_exit (status=status@entry=0) at exit.c:104
#23 0x0000000000445b80 in main (argc=1, argv=0x7fffffffdf08) at main.c:458
(gdb)
They may be unexported upon shutdown.
Program received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff48271db in _g_log_abort (breakpoint=1) at gmessages.c:316
316 G_BREAKPOINT ();
(gdb) bt
#0 0x00007ffff48271db in g_logv (breakpoint=1) at gmessages.c:316
#1 0x00007ffff48271db in g_logv (log_domain=0x7ffff488d8ce "GLib", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffd4d0) at gmessages.c:1073
#2 0x00007ffff482734f in g_log (log_domain=log_domain@entry=0x7ffff488d8ce "GLib", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7ffff48971dd "%s: assertion '%s' failed") at gmessages.c:1111
#3 0x00007ffff4827389 in g_return_if_fail_warning (log_domain=log_domain@entry=0x7ffff488d8ce "GLib", pretty_function=pretty_function@entry=0x7ffff48e7d00 <__func__.5406> "g_variant_is_object_path", expression=expression@entry=0x7ffff48e9af2 "string != NULL") at gmessages.c:1120
#4 0x00007ffff485511a in g_variant_is_object_path (string=<optimized out>) at gvariant.c:1351
#5 0x00007ffff4855129 in g_variant_new_object_path (object_path=0x0) at gvariant.c:1325
#6 0x00000000004b9567 in _dispatcher_call (dhcp6_props=<synthetic pointer>, dhcp4_props=<synthetic pointer>, ip6_builder=0x7fffffffd7b0, ip4_builder=0x7fffffffd730, dev_builder=0x7fffffffd6b0, device=0x9621f0 [NMDeviceEthernet]) at nm-dispatcher.c:242
#7 0x00000000004b9567 in _dispatcher_call (action=action@entry=DISPATCHER_ACTION_VPN_DOWN, blocking=blocking@entry=1, connection=<optimized out>, device=device@entry=0x9621f0 [NMDeviceEthernet], vpn_iface=0x9e2650 "tun1", vpn_ip4_config=vpn_ip4_config@entry=0x0, vpn_ip6_config=0x0, callback=0x0, user_data=0x0, out_call_id=0x0) at nm-dispatcher.c:545
#8 0x00000000004b98c2 in nm_dispatcher_call_vpn_sync (action=action@entry=DISPATCHER_ACTION_VPN_DOWN, connection=<optimized out>, parent_device=parent_device@entry=0x9621f0 [NMDeviceEthernet], vpn_iface=<optimized out>, vpn_ip4_config=vpn_ip4_config@entry=0x0, vpn_ip6_config=vpn_ip6_config@entry=0x0) at nm-dispatcher.c:740
#9 0x0000000000571986 in _set_vpn_state (connection=0xa08270 [NMVpnConnection], vpn_state=<optimized out>, reason=NM_VPN_CONNECTION_STATE_REASON_SERVICE_STOPPED, quitting=1) at vpn-manager/nm-vpn-connection.c:427
#10 0x00000000005764b6 in nm_vpn_connection_disconnect (connection=<optimized out>, reason=<optimized out>, quitting=<optimized out>) at vpn-manager/nm-vpn-connection.c:1909
#11 0x000000000057759e in nm_vpn_service_stop_connections (service=0x9aa1c0 [NMVpnService], quitting=1, reason=NM_VPN_CONNECTION_STATE_REASON_SERVICE_STOPPED) at vpn-manager/nm-vpn-service.c:149
#12 0x0000000000576e12 in dispose (object=0x9175a0 [NMVpnManager]) at vpn-manager/nm-vpn-manager.c:284
#13 0x00007ffff4b24fec in g_object_unref (_object=0x9175a0) at gobject.c:3137
#14 0x00000000004d0e75 in dispose (object=0x88a2c0 [NMManager]) at nm-manager.c:5061
#15 0x00007ffff4b24fec in g_object_unref (_object=0x88a2c0) at gobject.c:3137
#16 0x0000000000444e08 in _nm_singleton_instance_destroy () at NetworkManagerUtils.c:138
#17 0x00007ffff7de97b7 in _dl_fini () at dl-fini.c:252
#18 0x00007ffff4444778 in __run_exit_handlers (status=status@entry=0, listp=0x7ffff47d0618 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true) at exit.c:82
#19 0x00007ffff44447c5 in __GI_exit (status=status@entry=0) at exit.c:104
#20 0x0000000000445b80 in main (argc=1, argv=0x7fffffffdee8) at main.c:458
(gdb)
This downgrades the following warning down to debug-level.
<warn> Could not get scan request result: GDBus.Error:fi.w1.wpa_supplicant1.Interface.ScanError: Scan request rejected
It seems this ~error~ happens regularly, so warning about it is overly
alarming.
When the DHCPv6 lease received from the server contains multiple
addresses, dhclient generates a new BOUND event for each of
them. Instead of overwriting the previous IP6 configuration for each
BOUND event, we should try to detect if the new configuration belongs
to the same lease and merge its addresses with the existing one in
such case.
This allows NetworkManager to configure multiple addresses on an
interface via DHCPv6.
https://bugzilla.gnome.org/show_bug.cgi?id=681764https://bugzilla.redhat.com/show_bug.cgi?id=1244293
When unexporting an object, we might have a notification
pending. When the notification is finally processed, it
would find no "priv->interfaces" and raise an assertion
"idle_emit_properties_changed: assertion 'signal_id != 0' failed"
https://bugzilla.redhat.com/show_bug.cgi?id=1253326
Fixes: 073991f5a8
It might just be that we didn't see it yet; either on daemon startup on in a
race. The nm_platform_*_add() deals with the device already being there in
_link_add_check_existing().
NetworkManager:ERROR:devices/nm-device-bridge.c:402:create_and_realize: assertion failed: (nm_device_get_ifindex (device) <= 0)
Program received signal SIGABRT, Aborted.
0x00007ffff46965d7 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
Missing separate debuginfos, use: debuginfo-install bluez-libs-5.23-4.el7.x86_64
(gdb) bt
#0 0x00007ffff46965d7 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007ffff4697cc8 in __GI_abort () at abort.c:90
#2 0x00007ffff4a916d5 in g_assertion_message (domain=domain@entry=0x5a5088 "NetworkManager", file=file@entry=0x59b0f2 "devices/nm-device-bridge.c", line=line@entry=402, func=func@entry=0x59b3f0 <__FUNCTION__.29169> "create_and_realize", message=message@entry=0xa76a30 "assertion failed: (nm_device_get_ifindex (device) <= 0)") at gtestutils.c:2292
#3 0x00007ffff4a9176a in g_assertion_message_expr (domain=domain@entry=0x5a5088 "NetworkManager", file=file@entry=0x59b0f2 "devices/nm-device-bridge.c", line=line@entry=402, func=func@entry=0x59b3f0 <__FUNCTION__.29169> "create_and_realize", expr=expr@entry=0x59aef8 "nm_device_get_ifindex (device) <= 0") at gtestutils.c:2307
#4 0x0000000000447cb6 in create_and_realize (device=0xa77f40 [NMDeviceBridge], connection=0x8d0200, parent=<optimized out>, out_plink=0x7fffffffd700, error=0x0) at devices/nm-device-bridge.c:402
#5 0x000000000045d560 in nm_device_create_and_realize (self=self@entry=0xa77f40 [NMDeviceBridge], connection=connection@entry=0x8d0200, parent=<optimized out>, error=error@entry=0x0)
at devices/nm-device.c:1594
#6 0x00000000004d4b64 in system_create_virtual_device (self=self@entry=0x8802b0 [NMManager], connection=connection@entry=0x8d0200, error=error@entry=0x0) at nm-manager.c:983
#7 0x00000000004d4d71 in system_create_virtual_devices (self=0x8802b0 [NMManager]) at nm-manager.c:1022
#8 0x00000000004d47a5 in add_device (self=<optimized out>, device=<optimized out>, try_assume=<optimized out>) at nm-manager.c:1785
#9 0x00000000004d501f in platform_link_added (self=self@entry=0x8802b0 [NMManager], ifindex=<optimized out>, plink=plink@entry=0xa7f810) at nm-manager.c:1887
#10 0x00000000004d7c24 in nm_manager_start (self=0x8802b0 [NMManager]) at nm-manager.c:1959
#11 0x00000000004d7c24 in nm_manager_start (self=self@entry=0x8802b0 [NMManager], error=error@entry=0x7fffffffd930) at nm-manager.c:4178
#12 0x00000000004459ec in main (argc=1, argv=0x7fffffffda88) at main.c:442
(gdb)
It is not uncommon to see first a "disown" message before "disposing".
That alone does not yet indicate anything wrong or a leak. Remove that
overly alarming part of the logging message.
