nm-applet crashed with SIGSEGV in g_hash_table_foreach()

stacktrace:

#0 g_hash_table_foreach (hash_table=0x0, func=0x7fe3f250d910 <hashtable_foreach_with_values>, user_data=0x7fff2a991d90) at /build/buildd/glib2.0-2.29.6/./glib/ghash.c:1343
#1 0x00007fe3f250dd7e in hashtable_iterator (hash_type=33380976, instance=0x0, iterator=0x7fe3f2509ea0 <marshal_map_entry>, user_data=0x7fff2a991e30) at dbus-gvalue-utils.c:608
#2 0x00007fe3f2509192 in marshal_map (iter=0x7fff2a991e90, value=0x7fe3e009d420) at dbus-gvalue.c:1716
#3 0x00007fe3f2502c15 in dbus_g_proxy_marshal_args_to_message (proxy=<value optimized out>, method=0x7fe3f29896f3 "AddAndActivateConnection", args=0x210e800) at dbus-gproxy.c:2244
#4 0x00007fe3f2502cc1 in dbus_g_proxy_begin_call_internal (proxy=0x1dde550, method=0x7fe3f29896f3 "AddAndActivateConnection",
    notify=0x7fe3f29708d0 <org_freedesktop_NetworkManager_add_and_activate_connection_async_callback>, user_data=0x20b0bb0, destroy=0x7fe3f29708c0 <_dbus_glib_async_data_free>, args=<value optimized out>,
    timeout=-1) at dbus-gproxy.c:2277
#5 0x00007fe3f25056c2 in dbus_g_proxy_begin_call (proxy=0x1dde550, method=0x7fe3f29896f3 "AddAndActivateConnection",
    notify=0x7fe3f29708d0 <org_freedesktop_NetworkManager_add_and_activate_connection_async_callback>, user_data=0x20b0bb0, destroy=0x7fe3f29708c0 <_dbus_glib_async_data_free>,
    first_arg_type=<value optimized out>) at dbus-gproxy.c:2531
#6 0x00007fe3f29726e9 in org_freedesktop_NetworkManager_add_and_activate_connection_async (client=<value optimized out>, partial=<value optimized out>, device=<value optimized out>,
    specific_object=<value optimized out>, callback=<value optimized out>, user_data=0x1d9a220) at nm-client-bindings.h:175
#7 nm_client_add_and_activate_connection (client=<value optimized out>, partial=<value optimized out>, device=<value optimized out>, specific_object=<value optimized out>, callback=<value optimized out>,
    user_data=0x1d9a220) at nm-client.c:772
#8 0x0000000000417cdd in applet_menu_item_activate_helper_new_connection (connection=<value optimized out>, auto_created=<value optimized out>, canceled=<value optimized out>, user_data=0x7fe3e0018a70)
    at applet.c:525
#9 0x000000000042b319 in wireless_new_auto_connection (device=<value optimized out>, dclass_data=<value optimized out>, callback=<value optimized out>, callback_data=<value optimized out>)
    at applet-device-wifi.c:539
#10 0x0000000000418a02 in applet_menu_item_activate_helper (device=0x1e110a0, connection=<value optimized out>, specific_object=<value optimized out>, applet=0x1d9a220, dclass_data=0x7fe3e0047140)
    at applet.c:604
#11 0x00007fe3f1e4eda4 in g_closure_invoke (closure=0x7fe3e0044ed0, return_value=0x0, n_param_values=1, param_values=0x210fee0, invocation_hint=<value optimized out>)
    at /build/buildd/glib2.0-2.29.6/./gobject/gclosure.c:771
#12 0x00007fe3f1e60ccb in signal_emit_unlocked_R (node=<value optimized out>, detail=0, instance=0x2112e70, emission_return=0x0, instance_and_params=0x210fee0)
    at /build/buildd/glib2.0-2.29.6/./gobject/gsignal.c:3256
#13 0x00007fe3f1e6a2d7 in g_signal_emit_valist (instance=<value optimized out>, signal_id=<value optimized out>, detail=<value optimized out>, var_ar...

Sorry if I set to invalid but at now there's no other build to see if it is reproducible again

On an up-to-date Oneiric, just uploaded via apport, but only confirmed now. Not sure if the report still gets uploaded, in case it's still in /var/crash, but has over 4MB.

We don't need another report; the full backtrace is on this report already. Also, downgrading to libglib2.0-0 2.29.4-0ubuntu1 still appears to resolve issues. It seems to be because the hash_table become NULL at some point in hashtable_map() but I can't seem to figure out why.

An now I can't reproduce this anymore, so marking this Incomplete until we can get a clearer idea of what triggers this and whether it's still an issue.

Still here, still kicking and screaming ;-)

System updated with Seb's libglib2.0-0 of today.

Jun 14 11:36:12 xango3 kernel: [ 71.862360] nm-applet[2897]: segfault at 44 ip 00007fb3bfab0a3a sp 00007fff87c29c30 error 4 in libglib-2.0.so.0.2908.0[7fb3bfa7e000+ec000]

Yeah, we finally tracked it down to an issue in NetworkManager for the AddAndActivateConnection() dbus method; I'm preparing the package.

Great !!
Still reproducible in 20110614 clicking on the NM icon and choosing a wireless network

This bug was fixed in the package network-manager - 0.8.9997+git.20110614t173923.b4a72d1-0ubuntu1

---------------
network-manager (0.8.9997+git.20110614t173923.b4a72d1-0ubuntu1) oneiric; urgency=low

  * upstream snapshot 2011-06-14 17:39:23 (GMT)
    + b4a72d1ad794aef4c623fd530fc38ceb9b95456d
    - libnm-glib: fix crash for AddAndActivateConnection (LP: #795871)
 -- Mathieu Trudel-Lapierre <email address hidden> Tue, 14 Jun 2011 15:12:50 -0400

Hi,

I would like to share some informations with you related to this bug. I am working on Ubuntu 11.04 and I reproduce the bug not directly with the nm-applet but in a different context when I try to link a basic QT application with an other library (in my case the Orfeo ToolBox library).

Basically, the declaration of a QApplication app(argc, argv) linked with an other library provoke the same crash with SIGSEGV in g_hash_table_foreach(). Note that if I call the program through a remote terminal (with ssh for example) the problem does not appear.

I'm really stuck in finding from where the problem can come from. I'll be interested if you have information on how this bug was solved in the case of the nm-applet (I saw similar problems with other Ubuntu applications like empathy, ekiga but I didn't find really informations on where the problem comes from (the shared library? glib? Qt?...)

Thank you in advance.

the corresponding backtrace:

0x00007fffe76c5a00 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#1 0x00007fffe7bc9473 in g_hash_table_foreach () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007fffe76c7980 in g_param_spec_pool_list () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#3 0x00007fffe76bcfe4 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#4 0x00007fffe76da333 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#5 0x00007fffe76dcf44 in g_type_class_ref () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#6 0x00007fffe76c11be in g_object_new_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#7 0x00007fffe76c1621 in g_object_new () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#8 0x00007fffd720012b in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#9 0x00007fffd720732b in g_bus_get_sync () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#10 0x00007fffd749ab54 in ?? () from /usr/lib/libgconf-2.so.4
#11 0x00007fffd749adc2 in gconf_activate_server () from /usr/lib/libgconf-2.so.4
#12 0x00007fffd74a48b4 in ?? () from /usr/lib/libgconf-2.so.4
#13 0x00007fffd74a517f in ?? () from /usr/lib/libgconf-2.so.4
#14 0x00007fffd74a5674 in gconf_engine_get_default () from /usr/lib/libgconf-2.so.4
#15 0x00007fffd74ab671 in gconf_client_get_default () from /usr/lib/libgconf-2.so.4
#16 0x00007fffed9c2aa3 in ?? () from /usr/lib/libQtGui.so.4
#17 0x00007fffed6b648b in ?? () from /usr/lib/libQtGui.so.4
#18 0x00007fffed63e4f6 in QApplicationPrivate::construct(_XDisplay*, unsigned long, unsigned long) () from /usr/lib/libQtGui.so.4
#19 0x00007fffed63edd1 in QApplication::QApplication(int&, char**, int) () from /usr/lib/libQtGui.so.4
#20 0x000000000041b078 in otbWrapperQtWidgetParameterGroup (argc=1, argv=0x7fffffffddc0) at /home/grizonnetm/projets/otb/src/OTB/Testing/Code/Wrappers/Qt/otbWrapperQtWidgetParameterFactory.cxx:140
#21 0x0000000000415e2c in main (ac=2, av=0x7fffffffddb8) at /home/grizonnetm/projets/otb/src/OTB/Code/Testing/otbTestMain.h:295

Manuel

Manuel,

This bug was already fixed; on an up to date machine running 11.10 you wouldn't be getting hit by it. Not sure if 11.04 is affected.

Now, this kind of failure just means you're probably trying to do stuff on unref'd variables; perhaps because the hash table has already been freed but it could be for a variety of reasons, all of them dependent on the application's code. I suggest instead to post your issue on a side like StackExchange.