Version-Release number of selected component: NetworkManager-0.9.9.0-20.git20131003.fc20 Additional info: reporter: libreport-2.1.9 backtrace_rating: 4 cmdline: /usr/sbin/NetworkManager --no-daemon crash_function: _g_log_abort executable: /usr/sbin/NetworkManager kernel: 3.11.10-301.fc20.x86_64 runlevel: N 5 type: CCpp uid: 0 Truncated backtrace: Thread no. 1 (4 frames) #2 _g_log_abort at gmessages.c:255 #5 get_next_cb at settings/nm-agent-manager.c:1023 #6 get_callback at settings/nm-secret-agent.c:253 #7 complete_pending_call_and_unlock at dbus-connection.c:2314
Created attachment 859871 [details] File: backtrace
Created attachment 859872 [details] File: cgroup
Created attachment 859873 [details] File: core_backtrace
Created attachment 859874 [details] File: dso_list
Created attachment 859875 [details] File: environ
Created attachment 859876 [details] File: limits
Created attachment 859877 [details] File: maps
Created attachment 859878 [details] File: open_fds
Created attachment 859879 [details] File: proc_pid_status
Created attachment 859880 [details] File: var_log_messages
Please consider updating NetworkManager. There were some changes in the code. Nevertheless, there is still an issue upstream. jk/secret-agent-fix branch contains a fix.
the change seems generally correct, but can you explain how the current code is causing problems?
Agreed that the change seems correct, and may actually "fix" the bug but not the actual root cause. --- So the actual crash here appears to be due to agent_dbus_owner == NULL, and thus the creation of the auth chain fails because NM can't create an auth chain for the agent in get_next_cb(). So the question is why agent_dbus_owner is NULL... agent_dbus_owner comes from nm_secret_agent_get_dbus_owner(), and when creating the agent, the owner must be valid. The only place the owner is freed is nm-secret-agent.c in dispose(). So for agent_dbus_owner to be NULL, the current agent must have been already disposed. For the current agent to already be disposed, it must have had remove_agent() called on it, since (barring refcount problems) that's the only place that agents are disposed of. But that's really odd, because the code takes pains to ensure that when an agent is disposed, it gets removed from req->pending, and can never become the current agent. And if it's already the current agent, then it should get dropped from the request, and the next agent asked. ---- I did see one thing though. get_done_cb() uses: g_return_if_fail (call_id == parent->current_call_id); to ensure that a response from some agent that we don't care about anymore is ignored. Well, it turns out that call_id and parent->current_call_id are the return value from dbus_g_proxy_begin_call(), which is a counter that starts at 1 and counts up for each call to that proxy object. But *each* agent (and therefore each proxy) will start counting at 1. So NM sends a request to agent A, and then drops agent A, and then sends a request to agent B, and then finally agent A replies, there's a chance that NM thinks that agent A's response is actually for agent B. I don't see how that could cause the crash above, but it's worth noting and probably worth fixing, by having NMSecretAgent pass back the pointer to 'r' (which would still be opaque) instead of r->call, to ensure uniqueness.
Pushed to upstream master: 4141e69 settings: free memory in finalize(), not in dispose() in NMSecretAgent (rh #1061911) However, I leave the bug opened, so that it can be inspected deeper with regards to comment 13.
NetworkManager-0.9.9.0-34.git20131003.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/NetworkManager-0.9.9.0-34.git20131003.fc20
Package NetworkManager-0.9.9.0-34.git20131003.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing NetworkManager-0.9.9.0-34.git20131003.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-4964/NetworkManager-0.9.9.0-34.git20131003.fc20 then log in and leave karma (feedback).
NetworkManager-0.9.9.0-35.git20131003.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/NetworkManager-0.9.9.0-35.git20131003.fc20
NetworkManager-0.9.9.0-36.git20131003.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/NetworkManager-0.9.9.0-36.git20131003.fc20
NetworkManager-0.9.9.0-37.git20131003.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/NetworkManager-0.9.9.0-37.git20131003.fc20
NetworkManager-0.9.9.0-38.git20131003.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/NetworkManager-0.9.9.0-38.git20131003.fc20
NetworkManager-0.9.9.0-38.git20131003.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.