Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1056133 - [abrt] NetworkManager: _g_log_abort(): NetworkManager killed by SIGABRT
Summary: [abrt] NetworkManager: _g_log_abort(): NetworkManager killed by SIGABRT
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 20
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
URL: https://retrace.fedoraproject.org/faf...
Whiteboard: abrt_hash:df769d09c12057fc1c1b2258a6c...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-21 14:47 UTC by ssabchew
Modified: 2014-04-22 03:59 UTC (History)
5 users (show)

Fixed In Version: NetworkManager-0.9.9.0-38.git20131003.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-04-22 03:59:13 UTC


Attachments (Terms of Use)
File: backtrace (deleted)
2014-01-21 14:47 UTC, ssabchew
no flags Details
File: cgroup (deleted)
2014-01-21 14:48 UTC, ssabchew
no flags Details
File: core_backtrace (deleted)
2014-01-21 14:48 UTC, ssabchew
no flags Details
File: dso_list (deleted)
2014-01-21 14:48 UTC, ssabchew
no flags Details
File: environ (deleted)
2014-01-21 14:48 UTC, ssabchew
no flags Details
File: limits (deleted)
2014-01-21 14:48 UTC, ssabchew
no flags Details
File: maps (deleted)
2014-01-21 14:48 UTC, ssabchew
no flags Details
File: open_fds (deleted)
2014-01-21 14:48 UTC, ssabchew
no flags Details
File: proc_pid_status (deleted)
2014-01-21 14:48 UTC, ssabchew
no flags Details
File: var_log_messages (deleted)
2014-01-21 14:48 UTC, ssabchew
no flags Details

Description ssabchew 2014-01-21 14:47:48 UTC
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

Comment 1 ssabchew 2014-01-21 14:47:58 UTC
Created attachment 853270 [details]
File: backtrace

Comment 2 ssabchew 2014-01-21 14:48:01 UTC
Created attachment 853271 [details]
File: cgroup

Comment 3 ssabchew 2014-01-21 14:48:03 UTC
Created attachment 853272 [details]
File: core_backtrace

Comment 4 ssabchew 2014-01-21 14:48:07 UTC
Created attachment 853273 [details]
File: dso_list

Comment 5 ssabchew 2014-01-21 14:48:12 UTC
Created attachment 853274 [details]
File: environ

Comment 6 ssabchew 2014-01-21 14:48:14 UTC
Created attachment 853275 [details]
File: limits

Comment 7 ssabchew 2014-01-21 14:48:16 UTC
Created attachment 853276 [details]
File: maps

Comment 8 ssabchew 2014-01-21 14:48:18 UTC
Created attachment 853277 [details]
File: open_fds

Comment 9 ssabchew 2014-01-21 14:48:20 UTC
Created attachment 853278 [details]
File: proc_pid_status

Comment 10 ssabchew 2014-01-21 14:48:23 UTC
Created attachment 853279 [details]
File: var_log_messages

Comment 11 Pasi Karkkainen 2014-03-26 18:52:55 UTC
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.

Comment 12 Pasi Karkkainen 2014-03-31 10:22:36 UTC
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..

Comment 13 Jirka Klimes 2014-04-07 08:44:40 UTC
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.

Comment 14 Dan Williams 2014-04-09 19:44:10 UTC
(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?

Comment 15 Jirka Klimes 2014-04-14 14:39:17 UTC
(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()

Comment 16 Fedora Update System 2014-04-14 14:42:19 UTC
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

Comment 17 Fedora Update System 2014-04-15 12:00:09 UTC
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

Comment 18 Fedora Update System 2014-04-15 15:25:58 UTC
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).

Comment 19 Fedora Update System 2014-04-17 16:41:23 UTC
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

Comment 20 Fedora Update System 2014-04-22 03:59:13 UTC
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.


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