Version-Release number of selected component: NetworkManager-0.9.9.0-23.git20131003.fc20 Additional info: reporter: libreport-2.1.11 backtrace_rating: 4 cmdline: /usr/sbin/NetworkManager --no-daemon crash_function: _g_log_abort executable: /usr/sbin/NetworkManager kernel: 3.12.6-300.fc20.x86_64 runlevel: N 5 type: CCpp uid: 0 Truncated backtrace: Thread no. 1 (10 frames) #2 _g_log_abort at gmessages.c:255 #5 get_best_ip4_device at nm-policy.c:142 #6 check_activating_devices at nm-policy.c:928 #7 device_state_changed at nm-policy.c:1515 #8 ffi_call_unix64 at ../src/x86/unix64.S:76 #9 ffi_call at ../src/x86/ffi64.c:522 #10 g_cclosure_marshal_generic at gclosure.c:1454 #14 g_signal_emit_by_name at gsignal.c:3426 #15 nm_device_state_changed at devices/nm-device.c:6064 #16 _g_closure_invoke_va at gclosure.c:840
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.