Created attachment 766253 [details]
File: backtrace

Created attachment 766254 [details]
File: cgroup

Created attachment 766255 [details]
File: core_backtrace

Created attachment 766256 [details]
File: dso_list

Created attachment 766257 [details]
File: environ

Created attachment 766258 [details]
File: limits

Created attachment 766259 [details]
File: maps

Created attachment 766260 [details]
File: open_fds

Created attachment 766261 [details]
File: proc_pid_status

Created attachment 766262 [details]
File: xsession_errors

*** Bug 880380 has been marked as a duplicate of this bug. ***

Activated a wireless connection (had already connected with a wired connection).  The connection requires 802.1x but was not previously set up.  The connection I attempted to use was auto-discovered.  So, I would have expected to see a config popup asking me for connection details but nothing happened, just the nm-applet disappeared and then I was notified of the crash.

reporter:       libreport-2.1.5
backtrace_rating: 4
cmdline:        nm-applet
crash_function: inner_auth_combo_changed_cb
executable:     /usr/bin/nm-applet
kernel:         3.10.7-100.fc18.x86_64
package:        network-manager-applet-0.9.8.2-1.fc18
reason:         Process /usr/bin/nm-applet was killed by signal 6 (SIGABRT)
runlevel:       N 5
uid:            20992220

*** Bug 951944 has been marked as a duplicate of this bug. ***

*** Bug 953993 has been marked as a duplicate of this bug. ***

*** Bug 1003030 has been marked as a duplicate of this bug. ***

*** Bug 810004 has been marked as a duplicate of this bug. ***

The code that failed was:

-->  model = gtk_combo_box_get_model (GTK_COMBO_BOX (combo));
     gtk_combo_box_get_active_iter (GTK_COMBO_BOX (combo), &iter);
     gtk_tree_model_get (model, &iter, I_METHOD_COLUMN, &eap, -1);
-->  g_assert (eap);
in eap-method-fast.c:inner_auth_combo_changed_cb()

model was NULL and thus later eap was NULL as well.

And the model was NULL because eap_method_get_type() failed before in
inner_auth_combo_init():
    auth_model = gtk_list_store_new (2, G_TYPE_STRING, eap_method_get_type ())

The problem looks like a threading issue. We should use G_DEFINE_BOXED_TYPE to be thread save, see attached patch.

Created attachment 794625 [details]
[PATCH]  eap: use G_DEFINE_BOXED_TYPE to be thread-safe

Patch to use G_DEFINE_BOXED_TYPE for registering GType instead of home-brewed functions.

The patch is also available in upstream branch jklimes/rh979123-eap-crash.

Unfortunately, my testing showed that the patch didn't fixed the bug even if it looks like a right thing to do.
Instead of a crash, I experienced nm-applet to be stuck:
Thread 1 (Thread 0x7fb6baa09a00 (LWP 9449)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:165
#1  0x00000030d2c8501f in g_cond_wait (cond=cond@entry=0x30d2f213a0 <g_once_cond>, mutex=mutex@entry=0x30d2f21398 <g_once_mutex>) at gthread-posix.c:748
#2  0x00000030d2c6b75b in g_once_init_enter (location=location@entry=0x7fb6bac59ff0 <g_define_type_id__volatile.50831>) at gthread.c:682
#3  0x00007fb6baa48b20 in eap_method_get_type () at eap-method.c:40
#4  0x00007fb6baa4cb66 in inner_auth_combo_init (secrets_only=1, s_8021x=0x1b17d20 [NMSetting8021x], connection=0x1b1f830 [NMConnection], method=0x15d69f0) at eap-method-fast.c:244
#5  eap_method_fast_new (ws_parent=<optimized out>, connection=0x1b1f830 [NMConnection], is_editor=<optimized out>, secrets_only=1) at eap-method-fast.c:419
#6  0x00007fb6baa455dd in ws_802_1x_auth_combo_init (sec=0x1b25ba0, combo_name=0x7fb6baa53038 "dynamic_wep_auth_combo", combo_label=0x7fb6baa5304f "dynamic_wep_auth_label", auth_combo_changed_cb=
    0x7fb6baa48150 <auth_combo_changed_cb>, connection=0x1b1f830 [NMConnection], is_editor=0, secrets_only=1) at wireless-security.c:403
#7  0x00007fb6baa4836f in ws_dynamic_wep_new (connection=0x1b1f830 [NMConnection], is_editor=is_editor@entry=0, secrets_only=secrets_only@entry=1) at ws-dynamic-wep.c:132
#8  0x00007fb6baa3a86f in security_combo_init (self=self@entry=0x7fb6ac00c500 [NMAWifiDialog], secrets_only=1) at nm-wifi-dialog.c:934
#9  0x00007fb6baa3ba92 in internal_init (self=self@entry=0x7fb6ac00c500 [NMAWifiDialog], specific_connection=specific_connection@entry=0x1b1f830 [NMConnection], specific_device=
    0x167dd00 [GtkListStore], specific_device@entry=0x0, secrets_only=secrets_only@entry=1, create=create@entry=0) at nm-wifi-dialog.c:1120
#10 0x00007fb6baa3ccb0 in nma_wifi_dialog_new (client=<optimized out>, settings=0x1634900 [NMRemoteSettings], connection=0x1b1f830 [NMConnection], device=device@entry=0x0, ap=ap@entry=0x0, 
    secrets_only=secrets_only@entry=1) at nm-wifi-dialog.c:1311
#11 0x0000000000421a86 in wifi_get_secrets (req=0x1681580, error=0x7fff05b28578) at applet-device-wifi.c:1671
#12 0x00000000004183c4 in get_existing_secrets_cb (agent=<optimized out>, connection=<optimized out>, secrets=<optimized out>, secrets_error=<optimized out>, user_data=<optimized out>)
    at applet.c:2938
#13 0x000000000041a43a in keyring_find_secrets_cb (source=<optimized out>, result=<optimized out>, user_data=0x167de50) at applet-agent.c:429
#14 0x00000030d586dff7 in g_simple_async_result_complete (simple=0x1a0ff50 [GSimpleAsyncResult]) at gsimpleasyncresult.c:775
#15 0x00000030ee21a979 in on_search_secrets () from /lib64/libsecret-1.so.0
#16 0x00000030d586dff7 in g_simple_async_result_complete (simple=0x1a2ea50 [GSimpleAsyncResult]) at gsimpleasyncresult.c:775
#17 0x00000030d586e0f9 in complete_in_idle_cb (data=<optimized out>) at gsimpleasyncresult.c:787
#18 0x00000030d2c47a55 in g_main_dispatch (context=0x1498a30) at gmain.c:2715
#19 g_main_context_dispatch (context=context@entry=0x1498a30) at gmain.c:3219
#20 0x00000030d2c47d88 in g_main_context_iterate (context=0x1498a30, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3290
#21 0x00000030d2c48182 in g_main_loop_run (loop=0x14b3f80) at gmain.c:3484
#22 0x0000000000411647 in main (argc=1, argv=0x7fff05b288c8) at main.c:106

See http://ur1.ca/fed02 for the full trace.

I am not completely sure about the reproducer, but it seems to be this:
Create two EAP-enabled connections:
- Wi-Fi with WPA Enterprise
- Ethernet with 802.1X security enabled
and try to activate them simultaneously.

Also, these are the related glib assertions:
(nm-applet:9449): GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion `g_type_from_name (name) == 0' failed

(nm-applet:9449): GLib-CRITICAL **: g_once_init_leave: assertion `result != 0' failed

(nm-applet:9449): Gtk-WARNING **: gtkliststore.c:447: Invalid type (null)

(nm-applet:9449): Gtk-CRITICAL **: gtk_list_store_append: assertion `GTK_IS_LIST_STORE (list_store)' failed

(nm-applet:9449): Gtk-CRITICAL **: gtk_list_store_set_valist: assertion `GTK_IS_LIST_STORE (list_store)' failed

(nm-applet:9449): Gtk-CRITICAL **: gtk_list_store_append: assertion `GTK_IS_LIST_STORE (list_store)' failed

(nm-applet:9449): Gtk-CRITICAL **: gtk_list_store_set_valist: assertion `GTK_IS_LIST_STORE (list_store)' failed

The patch is fine, even if it doesn't fix the bug.

> See http://ur1.ca/fed02 for the full trace.

no longer there.

This might be related to https://bugzilla.gnome.org/show_bug.cgi?id=674885, in which case the only good workaround is to use g_type_ensure() to make sure the types get registered before they might be needed from another thread.

(Although... nm-applet doesn't use threads of its how, so why are its types getting referenced from other threads?)

The patch pushed:
https://git.gnome.org/browse/network-manager-applet/commit/?id=36a316be6cb424552782970c48305990e5af8437

Anyway, the bug needs more testing to find out what's going on. Dan, thanks for pointing to bgo 674885. It seems the issue described there could be the same.

*** Bug 1011848 has been marked as a duplicate of this bug. ***

This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.