chewie-network-menu-server crashes after enabling a connection via indicator

[Sergio Schvezov]

Hardware=manta
Build=20130628 flipped

Steps to reproduce:
1- Ensure no active network connection
2- Connect to an SSID for the first time

Expected result:
After the connection is completed, the indicator refreshes the network list, without repopulating the indicator.

Actual result:
Network indicator displays 'Empty' quickly, and then the indicator gets repopulated, like if a crash happened in the server side.

[Ubuntu QA Website (ubuntuqa)]

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1195787

[Ricardo Salveti (rsalveti)]

Confirming, happening with mako and maguro as well.

[Ricardo Salveti (rsalveti)]

Moving to high as there's no easy way to change the wifi ap once you're connected, unless you restart the shell.

[Ricardo Salveti (rsalveti)]

This bug appears after a change in glib, as it works fine with the 2.26 series.

Some traces:
(gdb) bt full
#0 0x4025dcf6 in g_object_ref (_object=0x18c71f0) at gobject.c:2884
        __inst = 0x18c71f0
        __r = <optimized out>
        _g_boolean_var_ = <optimized out>
        object = 0x18c71f0
        old_val = <optimized out>
        __PRETTY_FUNCTION__ = "g_object_ref"
#1 0x401ee382 in _nm_object_cache_get (path=0x18ce3a0 "\300\240\214\001Xڊ\001`ٌ\001\001", path@entry=0x18c86a0 "/org/freedesktop/NetworkManager/AccessPoint/0") at nm-object-cache.c:64
        object = <optimized out>
#2 0x401e2ad6 in handle_object_property (synchronously=0, pi=0x18ada58, value=0x18d7d10, property_name=<optimized out>, self=0x18ca0c0) at nm-object.c:740
        priv = 0x18ca088
        obj = <optimized out>
        odata = 0x18ce3a0
        path = 0x18c86a0 "/org/freedesktop/NetworkManager/AccessPoint/0"
#3 handle_property_changed (self=self@entry=0x18ca0c0, dbus_name=<optimized out>, value=value@entry=0x18d7d10, synchronously=synchronously@entry=0) at nm-object.c:871
        priv = <optimized out>
        prop_name = 0x18dc978 "active-access-point"
        pi = 0x18ada58
        pspec = <optimized out>
        success = 0
        found = 1
        iter = <optimized out>
        __func__ = "handle_property_changed"
        __PRETTY_FUNCTION__ = "handle_property_changed"
#4 0x401e2bf6 in process_properties_changed (synchronously=0, properties=<optimized out>, self=0x18ca0c0) at nm-object.c:905
        iter = {dummy1 = 0x18d6d30, dummy2 = 0x18ea618, dummy3 = 0x48, dummy4 = 4, dummy5 = 26045744, dummy6 = 0x2}
        value = 0x18d7d10
        name = 0x18dd358
#5 process_properties_changed (self=0x18ca0c0, properties=<optimized out>, synchronously=0) at nm-object.c:893
        priv = <optimized out>
#6 0x4025cd28 in g_cclosure_marshal_VOID__BOXED (closure=0x18ad998, return_value=<optimized out>, n_param_values=<optimized out>, param_values=0x18ea600, invocation_hint=0xbefb758c, marshal_data=0x0) at gmarshal.c:1120
        callback = 0x401e2cad <properties_changed_proxy>
        cc = 0x18ad998
        data1 = 0x18c9098
        data2 = 0x18ca0c0
        __PRETTY_FUNCTION__ = "g_cclosure_marshal_VOID__BOXED"
#7 0x404cb3aa in marshal_dbus_message_to_g_marshaller (closure=0x18ad998, return_value=0x0, n_param_values=<optimized out>, param_values=<optimized out>, invocation_hint=0xbefb758c, marshal_data=0x0) at dbus-gproxy.c:1736
        value_array = 0x1900410
        c_marshaller = 0x4025cce1 <g_cclosure_marshal_VOID__BOXED>
        proxy = <optimized out>
        message = 0x18e2018
        gsignature = <optimized out>
        types = <optimized out>
        priv = 0x18c9070
        __PRETTY_FUNCTION__ = "marshal_dbus_message_to_g_marshaller"
#8 0x4025b08c in g_closure_invoke (closure=0x18ad998, return_value=return_value@entry=0x0, n_param_values=3, param_values=param_values@entry=0xbefb75d0, invocation_hint=invocation_hint@entry=0xbefb758c) at gclosure.c:777
        marshal = 0x404cb2d5 <marshal_dbus_message_to_g_marshaller>
        marshal_data = 0x0
        real_closure = 0x18ad988
        __PRETTY_FUNCTION__ = "g_closure_invoke"
#9 0x402674e4 in s...

[Ricardo Salveti (rsalveti)]

This is a side effect of https://git.gnome.org/browse/glib/commit/?id=31fde567a95ff8f50b6b0e75d4010da9b73514ed, which improves the data type, but causing side effects with apps not behaving properly.

A similar issue, but which happened with unity-panel-service: bug 1173262

[Nick Dedekind (nick-dedekind)]

I believe the problem with this is actually the menu models misbehaving inside qmenumodel & indicators-client.
From my investigation, it stopped working after a change in qmenumodel which treats the root index as invalid.
http://bazaar.launchpad.net/~phablet-team/qmenumodel/trunk/revision/68

This messes around with the indicators-client flattening model. The model is cleared and rebuilt, but the row is added on the root node, and the flat model doesn't handle the new invalid index correctly.

[Ricardo Salveti (rsalveti)]

This is still happening even with the new indicator code that landed in Unity8, because the issue is on the server side.

[Tony Espy (awe)]

I'm still seeing this happening on mako with image 20130724, and it's easily reproducible.

I *cannot* reproduce it on maguro.

[Tony Espy (awe)]

I double-checked on maguro, and chewie-network is *not* crashing, as the PID doesn't change after association.

[Ricardo Salveti (rsalveti)]

Not valid anymore since we stopped using chewie.

[Tony Espy (awe)]

Actually chewie was renamed, and although much of the code has been re-factored, we're still not 100% sure this has been fixed, so I've reset the status to Incomplete/Medium for now.