After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 693829 - "assertion `nm_connection_get_path (NM_CONNECTION (connection)) == NULL' failed"
"assertion `nm_connection_get_path (NM_CONNECTION (connection)) == NULL' failed"
Status: RESOLVED FIXED
Product: NetworkManager
Classification: Platform
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2013-02-14 17:33 UTC by Mantas Mikulėnas (grawity)
Modified: 2013-02-14 21:42 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
libnm-util, libnm-glib: fix NMConnection:path again (3.82 KB, patch)
2013-02-14 18:55 UTC, Dan Winship
committed Details | Review
core: fix a bug in NMSettingsConnection (1.30 KB, patch)
2013-02-14 19:00 UTC, Dan Winship
committed Details | Review

Description Mantas Mikulėnas (grawity) 2013-02-14 17:33:08 UTC
Latest NetworkManager-git is unable to connect (only tried wireless networks). The following error is logged to syslog every time I click on the network item:

    NetworkManager[405]: claim_connection: assertion `nm_connection_get_path (NM_CONNECTION (connection)) == NULL' failed

`git bisect` returns:

commit 24cda2bc367d9fafa847a82493a1adb9f3e53e47
Author: Dan Winship <danw@gnome.org>
Date:   Tue Feb 12 13:09:30 2013 -0500

    libnm-util, libnm-glib: Make NMRemoteConnection instantiable by NMObject
Comment 1 Dan Winship 2013-02-14 18:55:26 UTC
Created attachment 236118 [details] [review]
libnm-util, libnm-glib: fix NMConnection:path again

24cda2bc broke the ability to set NMConnection:path back to NULL after
it had been set, as part of a hack to try to make
NMRemoteConnection:dbus-path work. Fix that by moving the hack
entirely into NMRemoteConnection.

======

The problem is that when NMObject does:

	object = g_object_new (type,
	                       NM_OBJECT_DBUS_CONNECTION, connection,
	                       NM_OBJECT_DBUS_PATH, path,
	                       NULL);

GObject sees that it's not providing a value for the construct
property NMConnection:path, so it fills in the default value,
effectively turning the call into:

	object = g_object_new (type,
	                       NM_OBJECT_DBUS_CONNECTION, connection,
	                       NM_OBJECT_DBUS_PATH, path,
			       NM_CONNECTION_PATH, NULL,
	                       NULL);

and so NMRemoteConnection's attempt to set the path gets
overwritten. The previous fix was to ignore setting
NMConnection:path if the value was NULL, but this breaks places
that actually intended to do that. The new fix is to just rewrite
the initial property values in NMRemoteConnection's
constructor(), effectively turning the call into:

	object = g_object_new (type,
	                       NM_OBJECT_DBUS_CONNECTION, connection,
	                       NM_OBJECT_DBUS_PATH, path,
			       NM_CONNECTION_PATH, path,
	                       NULL);
Comment 2 Dan Winship 2013-02-14 19:00:04 UTC
Created attachment 236119 [details] [review]
core: fix a bug in NMSettingsConnection

nm_settings_connection_init() was calling nm_connection_set_path(),
but this was pointless since that would end up getting cleared by the
property's default value shortly after init() returned (and
claim_connection() depended on this). So remove that code.
Comment 3 Dan Williams 2013-02-14 20:14:32 UTC
Review of attachment 236119 [details] [review]:

Good
Comment 4 Dan Williams 2013-02-14 21:40:49 UTC
Review of attachment 236118 [details] [review]:

Looks good.
Comment 5 Dan Winship 2013-02-14 21:42:25 UTC
Attachment 236118 [details] pushed as 57327a6 - libnm-util, libnm-glib: fix NMConnection:path again
Attachment 236119 [details] pushed as b54a4e6 - core: fix a bug in NMSettingsConnection