Bug 1056133

Created attachment 853270 [details]
File: backtrace

Created attachment 853271 [details]
File: cgroup

Created attachment 853272 [details]
File: core_backtrace

Created attachment 853273 [details]
File: dso_list

Created attachment 853274 [details]
File: environ

Created attachment 853275 [details]
File: limits

Created attachment 853276 [details]
File: maps

Created attachment 853277 [details]
File: open_fds

Created attachment 853278 [details]
File: proc_pid_status

Created attachment 853279 [details]
File: var_log_messages

Any news about this bug? 

Network Manager mate-panel applet still crashes for me when I try to enable Mobile Broadband.. the system in question is fully updated Fedora 20 x86_64.

With NetworkManager-0.9.9.0-33.git20131003.fc20.x86_64 I'm able to get to Internet with the mate-desktop nm applet (it wasn't possible at all with the earlier versions), but it still crashes every now and then..

An assertion in get_best_ip4_device()

        req = nm_device_get_act_request (dev);
--->    g_assert (req);
        connection = nm_act_request_get_connection (req);
        g_assert (connection);

It can probably be triggered by bug 1083727.

(In reply to Jirka Klimes from comment #13)
> An assertion in get_best_ip4_device()
> 
>         req = nm_device_get_act_request (dev);
> --->    g_assert (req);
>         connection = nm_act_request_get_connection (req);
>         g_assert (connection);
> 
> It can probably be triggered by bug 1083727.

So this bug should be fixed by 5c1dee10cde3cc7cf74718650702dd124d46aa75 upstream which should probably be backported to F20.

-------

However, I think I found another bug while looking at the F20 sources, though I could be wrong.  I'm not sure whether it applies to git master too.

If the device is moved to DISCONNECTED state, it gets deactivated from nm_device_state_changed(), *before* the state is actually changed to DISCONNECTED.  Then in nm_device_deactivate() we get the following pattern:

clear_act_request (self);
...
nm_device_set_ip4_config (self, NULL, TRUE, &ignored);

So the device is still in ACTIVATED state, and when nm_device_set_ip4_config() is called that clears out the IPv4 config, which emits the notify::ip4-config signal.  The Policy listens for that signal and calls nm-policy.c::nm_device_set_ip4_config().  That calls nm_device_is_activating() which returns FALSE since priv->act_source_id is 0, since no activating is happening.  Then update_ip4_dns() or update_ip4_routing() gets called, and that calls get_best_ip4_config() and bad things happen.

Or am I missing something?

(In reply to Dan Williams from comment #14)
> (In reply to Jirka Klimes from comment #13)
> > An assertion in get_best_ip4_device()
> > 
> >         req = nm_device_get_act_request (dev);
> > --->    g_assert (req);
> >         connection = nm_act_request_get_connection (req);
> >         g_assert (connection);
> > 
> > It can probably be triggered by bug 1083727.
> 
> So this bug should be fixed by 5c1dee10cde3cc7cf74718650702dd124d46aa75
> upstream which should probably be backported to F20.
> 

Yeah, the bug is fixed by 5c1dee1. I'll backport it.

BTW, the reproducer is:
1) have a PIN secured SIM card
2) insert the modem
3) try to enable the modem (e.g with nmcli radio wwan on)

> -------
> 
> However, I think I found another bug while looking at the F20 sources,
> though I could be wrong.  I'm not sure whether it applies to git master too.
> 
> If the device is moved to DISCONNECTED state, it gets deactivated from
> nm_device_state_changed(), *before* the state is actually changed to
> DISCONNECTED.  Then in nm_device_deactivate() we get the following pattern:
> 
> clear_act_request (self);
> ...
> nm_device_set_ip4_config (self, NULL, TRUE, &ignored);
> 
> So the device is still in ACTIVATED state, and when
> nm_device_set_ip4_config() is called that clears out the IPv4 config, which
> emits the notify::ip4-config signal.  The Policy listens for that signal and
> calls nm-policy.c::nm_device_set_ip4_config().  That calls
> nm_device_is_activating() which returns FALSE since priv->act_source_id is
> 0, since no activating is happening.  Then update_ip4_dns() or
> update_ip4_routing() gets called, and that calls get_best_ip4_config() and
> bad things happen.
> 
> Or am I missing something?

Do you have a testcase that could have problems?
I just set breakpoints for "nm_device_state_changed", "device_state_changed", "device_ip4_config_changed", "get_best_ip4_device".

They are called in this order:
NMDevice::disconnect_cb()
NMDevice::nm_device_state_changed()
NMPolicy::device_ip4_config_changed()
NMPolicy::get_best_ip4_device()
NMActivationRequest::device_state_changed()
NMPolicy::device_state_changed()
...

The state in nm_device_state_changed() is DISCONNECTED, set by disconnect_cb(). So I see now problems later in get_best_ip4_device()

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

Package NetworkManager-0.9.9.0-36.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-36.git20131003.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-5044/NetworkManager-0.9.9.0-36.git20131003.fc20
then log in and leave karma (feedback).

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.