GNOME Bugzilla – Bug 763528
crash when clicking 'Network' icon
Last modified: 2016-03-29 10:19:16 UTC
gnome-control-center segfaults when I try to view network settings. (gdb) r Starting program: /usr/bin/gnome-control-center [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7fffcc763700 (LWP 19570)] [New Thread 0x7fffcbf62700 (LWP 19571)] [New Thread 0x7fffc3fff700 (LWP 19572)] [New Thread 0x7fffc37fe700 (LWP 19573)] [New Thread 0x7fffc260f700 (LWP 19574)] [New Thread 0x7fffc1e0e700 (LWP 19581)] (gnome-control-center:19566): libnm-glib-WARNING **: Unknown device type 16 (gnome-control-center:19566): libnm-glib-WARNING **: Unknown device type 16 [New Thread 0x7fffc160d700 (LWP 19582)] (gnome-control-center:19566): libnm-util-WARNING **: Ignoring invalid property 'route-data' (gnome-control-center:19566): libnm-util-WARNING **: Ignoring invalid property 'address-data' (gnome-control-center:19566): libnm-util-WARNING **: Ignoring invalid property 'addr-gen-mode' (gnome-control-center:19566): libnm-util-WARNING **: Ignoring invalid property 'route-data' (gnome-control-center:19566): libnm-util-WARNING **: Ignoring invalid property 'address-data' (gnome-control-center:19566): libnm-util-WARNING **: Ignoring invalid property 'route-data' (gnome-control-center:19566): libnm-util-WARNING **: Ignoring invalid property 'address-data' (gnome-control-center:19566): libnm-util-WARNING **: Ignoring invalid property 'route-data' (gnome-control-center:19566): libnm-util-WARNING **: Ignoring invalid property 'address-data' (gnome-control-center:19566): libnm-glib-WARNING **: replace_settings: error updating connection /org/freedesktop/NetworkManager/Settings/1 settings: (3) connection.type: requires presence of 'tun' setting in the connection ** libnm-util:ERROR:nm-connection.c:307:_get_type_setting: assertion failed: (base) Program received signal SIGABRT, Aborted. 0x00007fffef5cb507 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55 55 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt full
+ Trace 236064
> (gnome-control-center:19566): libnm-glib-WARNING **: Unknown device type 16 Means that you have a setting of type NM_DEVICE_TYPE_TUN. And if it's unknown, you either created the setting on a newer version of NetworkManager and are running an older version of NM, or the tun support is in a plugin that isn't installed on your machine. From the backtrace, the assertion is within libnm-util, which means that the Network panel (probably) can't avoid the crash itself. libnm-util:ERROR:nm-connection.c:307:_get_type_setting: assertion failed: (base) Reassigning to NetworkManager, to find a way to export the existing connection setting to reproduce the problem.
This is basically a dupe of bug 760907. I let the bugs depend on each other.
@Sam, can you detail which version of NetworkManager and libnm-glib you have?
You're absolutely right, it was version skew between libnm-util2 (0.9.10.0) and network-manager (1.1.91). Upgrading fixes the crash. BTW, I didn't create the tun connection in NM myself, but with systemd-networkd. I'd expect NM to consider it unmanaged. I think this would be https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755015 which hasn't been marked as forwarded upstream. Maybe https://bugzilla.gnome.org/show_bug.cgi?id=740967 applies? If you think so I'll mark it as forwarded downstream. There's one other weirdness; though both eth0 and robots show up in 'nmcli con' and in gnome-control-center, nm-connection-editor only lists eth0. It doesn't crash though.
(In reply to Sam Morris from comment #4) > There's one other weirdness; though both eth0 and robots show up in 'nmcli > con' and in gnome-control-center, nm-connection-editor only lists eth0. It > doesn't crash though. Erm, some context, those are the connections for my (managed) ethernet connection and my (desired unmanaged) TUN connection.
So, the wrong assertion was already fixed by https://cgit.freedesktop.org/cgit/?url=NetworkManager/NetworkManager/commit/&id=8c27a370ff70430225bd6a2408e32e332f872f2e Unfortunately, it's a bug in libnm-util that is triggered by newer NetworkManager version. Which is bad, because upgrading the server can break your client -- usually we want to continue supporting old clients. In this case, it cannot be really avoided. The solution is to fix/upgrade the client. In general, when using older library versions against a newer server it is to be expected that NetworkManager might expose connections with unknown properties/settings to the client. bug 760907 improved here in that libnm and libnm-glib better accept whatever the server sends and expose to the library user those properties that are recognized. -- this only matters if the libnm version differs from NetworkManager (or if there is a bug in either of them). For library users this has the unexpected(?) consequence, that a connection might not validate (according to it's own version of libnm/libnm-glib). For example, don't assume that setting = nm_connection_get_setting_by_name (connection, nm_connection_get_connection_type (connection)); g_assert (setting); is valid to do (as would be on a verified connection). Instead: type = nm_connection_get_connection_type (connection); setting = type ? nm_connection_get_setting_by_name (connection, type) : NULL; if (!setting) { /*handle me*/ } Closing this bug as fixed.