Bug 922855 - [abrt] NetworkManager-0.9.8.0-1.fc18: nm_secret_agent_cancel_secrets: Process /usr/sbin/NetworkManager was killed by signal 11 (SIGSEGV)
Summary: [abrt] NetworkManager-0.9.8.0-1.fc18: nm_secret_agent_cancel_secrets: Process...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 18
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:11ff104c97dca7fac64f23ad50f...
: 1011872 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-03-18 17:01 UTC by Kuba H
Modified: 2014-02-05 23:20 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-02-05 23:20:13 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
File: backtrace (17.27 KB, text/plain)
2013-03-18 17:02 UTC, Kuba H
no flags Details
File: cgroup (174 bytes, text/plain)
2013-03-18 17:02 UTC, Kuba H
no flags Details
File: core_backtrace (1.50 KB, text/plain)
2013-03-18 17:02 UTC, Kuba H
no flags Details
File: environ (114 bytes, text/plain)
2013-03-18 17:02 UTC, Kuba H
no flags Details
File: limits (1.29 KB, text/plain)
2013-03-18 17:02 UTC, Kuba H
no flags Details
File: maps (17.87 KB, text/plain)
2013-03-18 17:02 UTC, Kuba H
no flags Details
File: open_fds (1.63 KB, text/plain)
2013-03-18 17:02 UTC, Kuba H
no flags Details
File: proc_pid_status (901 bytes, text/plain)
2013-03-18 17:02 UTC, Kuba H
no flags Details

Description Kuba H 2013-03-18 17:01:13 UTC
Version-Release number of selected component:
NetworkManager-0.9.8.0-1.fc18

Additional info:
backtrace_rating: 4
cmdline:        /usr/sbin/NetworkManager --no-daemon
crash_function: nm_secret_agent_cancel_secrets
executable:     /usr/sbin/NetworkManager
kernel:         3.8.2-206.fc18.x86_64
uid:            0

Truncated backtrace:
Thread no. 1 (6 frames)
 #0 nm_secret_agent_cancel_secrets at nm-secret-agent.c:323
 #1 request_free at nm-agent-manager.c:471
 #2 g_hash_table_remove_internal at ghash.c:1274
 #3 dispose at nm-activation-request.c:448
 #5 nm_device_state_changed at nm-device.c:5180
 #6 queued_set_state at nm-device.c:5207

Comment 1 Kuba H 2013-03-18 17:02:04 UTC
Created attachment 712118 [details]
File: backtrace

Comment 2 Kuba H 2013-03-18 17:02:07 UTC
Created attachment 712119 [details]
File: cgroup

Comment 3 Kuba H 2013-03-18 17:02:10 UTC
Created attachment 712120 [details]
File: core_backtrace

Comment 4 Kuba H 2013-03-18 17:02:16 UTC
Created attachment 712121 [details]
File: environ

Comment 5 Kuba H 2013-03-18 17:02:22 UTC
Created attachment 712122 [details]
File: limits

Comment 6 Kuba H 2013-03-18 17:02:25 UTC
Created attachment 712123 [details]
File: maps

Comment 7 Kuba H 2013-03-18 17:02:27 UTC
Created attachment 712124 [details]
File: open_fds

Comment 8 Kuba H 2013-03-18 17:02:34 UTC
Created attachment 712125 [details]
File: proc_pid_status

Comment 9 Dan Williams 2013-03-19 20:21:33 UTC
Backtrace points to:

void
nm_secret_agent_cancel_secrets (NMSecretAgent *self, gconstpointer call)
{
	NMSecretAgentPrivate *priv;
	Request *r;

	g_return_if_fail (self != NULL);
	priv = NM_SECRET_AGENT_GET_PRIVATE (self);

--->	r = g_hash_table_lookup (priv->requests, call);
	g_return_if_fail (r != NULL);

	dbus_g_proxy_cancel_call (priv->proxy, (gpointer) call);

which implies that priv->requests is no longer valid, but since priv->requests is valid over the entire lifetime of the Agent that it's for, that implies the Agent itself has been freed already. Which is odd.

Comment 10 Dandim 2013-06-09 08:35:23 UTC
Crash after restart computer. previously i update NetworkManager from updates-testing. ABRT shows crash, but NetworkManager works good.

reporter:       libreport-2.1.4
backtrace_rating: 4
cmdline:        /usr/sbin/NetworkManager --no-daemon
crash_function: nm_secret_agent_cancel_secrets
executable:     /usr/sbin/NetworkManager
kernel:         3.9.4-200.fc18.x86_64
package:        NetworkManager-0.9.8.1-3.git20130514.fc18
reason:         Process /usr/sbin/NetworkManager was killed by signal 11 (SIGSEGV)
runlevel:       N 5
uid:            0

Comment 11 Dandim 2013-06-13 10:02:08 UTC
After every start KDE. I cant connect to wifi. Network applet (KDE) says (in czech): "čekám na ověření" (From Google translate: I am waiting for verification).
I must click (in Network manager) on red storno button. Network manager crashed. And i must type wireless password again. After this i succesfully connect.

Comment 12 Mark Rooks 2013-09-10 06:31:30 UTC
-I noticed there was a small key on the nm-applet
- I hovered on the applet and it said "waiting for authorization"
- I left clicked on nm-applet, then clicked on the wlan interface, which was the one "waiting for authorization"
- Nothing happened so I clicked the red cross and deleted the entry
- I then tried to attempt to the wlan interface again and that is when the crash occurred

reporter:       libreport-2.1.6
backtrace_rating: 4
cmdline:        /usr/sbin/NetworkManager --no-daemon
crash_function: nm_secret_agent_cancel_secrets
executable:     /usr/sbin/NetworkManager
kernel:         3.10.10-100.fc18.x86_64
package:        NetworkManager-0.9.8.2-1.fc18
reason:         Process /usr/sbin/NetworkManager was killed by signal 11 (SIGSEGV)
runlevel:       N 5
uid:            0

Comment 13 Jirka Klimes 2013-11-21 16:15:14 UTC
*** Bug 1011872 has been marked as a duplicate of this bug. ***

Comment 14 Jirka Klimes 2013-11-21 17:08:14 UTC
Well, I spent some time analysing this issue again. And fortunately, I have found the cause and managed to fix it this time :-)

The problem is that 'self' variable from comment 9 is already freed
(gdb) p *self
    $67 = {parent = {g_type_instance = {g_class = 0x0}, ref_count = 0, qdata = 0x0}}

Also, there is a problem with hash table:
GLib-CRITICAL **: g_hash_table_iter_next: assertion `ri->version == ri->hash_table->version' failed
See also
https://mail.gnome.org/archives/networkmanager-list/2013-September/msg00012.html

I have found the reason for this too and prepared a patch.

The patches are published for review in jk/agent-crash-fixes upstream branch.

Note:
Another maybe related fix is
http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=0c15e1c2ced9866b6f729585a41a7a2034f82ed0
I am not sure whether this fixes this bug or not. I tried with Fedora 20 NM with my added patches.

Comment 15 Dan Winship 2013-11-22 19:01:29 UTC
> agents: fix removing requests from hash table while iterating it

You don't need request_to_next_agent_cb(), you can just cast request_next_agent() to GDestroyNotify.

>+		pending_reqs = g_slist_prepend (pending_reqs, req);

The new value of pending_reqs doesn't get passed back to remove_agent() though, so remove_agent()'s pending_reqs will always remain NULL and you'll never call request_next_agent() on any of them.


The other patch looks good.

Comment 16 Dan Williams 2013-11-22 22:55:36 UTC
> pending_reqs = g_slist_prepend (pending_reqs, req);

Yeah, you need:

request_remove_agent (Request *req, NMSecretAgent *agent, GSList **pending_reqs)
{
...
   *pending_reqs = g_slist_prepend (*pending_reqs, req);
}

and pass the GSList* in with &.

Comment 17 Dan Williams 2013-11-22 23:12:30 UTC
At some point we should rewrite the AgentManager/Agent code.  That code is convoluted, confusing, and error prone, and I'm not very proud that I wrote most of it...  Rest of the patches look good though.

Comment 18 Jirka Klimes 2013-11-26 13:50:00 UTC
(In reply to Dan Winship from comment #15)
> > agents: fix removing requests from hash table while iterating it
> 
> You don't need request_to_next_agent_cb(), you can just cast
> request_next_agent() to GDestroyNotify.
> 
Yeah, I probably thought this is more explicit. Anyway, changed to use request_next_agent() directly now.

> >+		pending_reqs = g_slist_prepend (pending_reqs, req);
> 
> The new value of pending_reqs doesn't get passed back to remove_agent()
> though, so remove_agent()'s pending_reqs will always remain NULL and you'll
> never call request_next_agent() on any of them.
> 
> 
> The other patch looks good.
(In reply to Dan Williams from comment #16)
> > pending_reqs = g_slist_prepend (pending_reqs, req);
> 
> Yeah, you need:
> 
> request_remove_agent (Request *req, NMSecretAgent *agent, GSList
> **pending_reqs)
> {
> ...
>    *pending_reqs = g_slist_prepend (*pending_reqs, req);
> }
> 
> and pass the GSList* in with &.
Oh, sure. Fixed.

Rebased the branch to current master.

Comment 19 Dan Winship 2013-11-26 14:32:33 UTC
looks right now.

Comment 20 Jirka Klimes 2013-11-26 15:31:52 UTC
Pushed to master:
91a95dd agents: fix crash in nm_secret_agent_cancel_secrets() (rh #922855)
593f1aa agents: fix removing requests from hash table while iterating it

Comment 21 Jirka Klimes 2013-11-27 16:05:31 UTC
Backported to upstream nm-9-8:
bbf6a10 agents: fix crash in nm_secret_agent_cancel_secrets() (rh #922855)
b2312d4 agents: fix removing requests from hash table while iterating it

Comment 22 Fedora End Of Life 2013-12-21 15:45:33 UTC
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 23 Fedora End Of Life 2014-02-05 23:20:13 UTC
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.