Created attachment 678470 [details]
File: backtrace

Created attachment 678471 [details]
File: cgroup

Created attachment 678472 [details]
File: core_backtrace

Created attachment 678473 [details]
File: dso_list

Created attachment 678474 [details]
File: environ

Created attachment 678475 [details]
File: limits

Created attachment 678476 [details]
File: maps

Created attachment 678477 [details]
File: open_fds

Created attachment 678478 [details]
File: proc_pid_status

Created attachment 678479 [details]
File: var_log_messages

Relevant bits are:

Jan 14 12:37:32 localhost NetworkManager[896]: <info> Activation (wlan0) Stage 5 of 5 (IPv4 Commit) complete.
Jan 14 12:37:32 localhost NetworkManager[896]: <info> VPN service 'openvpn' appeared; activating connections
Jan 14 12:37:32 localhost NetworkManager[896]: <info> VPN plugin state changed: starting (3)
Jan 14 12:37:32 localhost NetworkManager[896]: <info> VPN connection 'openvpn-Swe' (Connect) reply received.
Jan 14 14:37:42 localhost NetworkManager[896]: <info> (wlan0): disconnecting for new activation request.
Jan 14 14:37:42 localhost NetworkManager[896]: <info> (wlan0): device state change: secondaries -> disconnected (reason 'none') [90 30 0]
Jan 14 14:37:42 localhost NetworkManager[896]: <info> (wlan0): deactivating device (reason 'none') [0]
Jan 14 14:37:42 localhost NetworkManager[896]: <info> (wlan0): canceled DHCP transaction, DHCP client pid 2898
Jan 14 14:37:42 localhost NetworkManager[896]: <info> (wlan0): device state change: disconnected -> failed (reason 'secondary-connection-failed') [30 120 54]
Jan 14 14:37:42 localhost abrt[2918]: Saved core dump of pid 896 (/usr/sbin/NetworkManager) to /var/spool/abrt/ccpp-2013-01-14-14:37:42-896 (27418624 bytes)

static void
activation_failure_handler (NMDevice *dev)
{
	NMDeviceWifi *self = NM_DEVICE_WIFI (dev);
	NMAccessPoint *ap;
	NMConnection *connection;

	connection = nm_device_get_connection (dev);
>>>>	g_assert (connection);


The "new activation request" is what kills things here, because when the new request comes in, internal_activate_device() calls:

nm_device_state_changed (device,
                         NM_DEVICE_STATE_DISCONNECTED,
                         NM_DEVICE_STATE_REASON_NONE);

which then ends up calling nm_device_deactivate(), which clears out the activating request and thus the device's NMConnection.  That's why the assertion triggers.  But the real bug is why the Wifi device is even getting to this code, given that the device should already be disconnected and the wifi code shouldn't be handling this as a failure.

So after being deactivated, the VPN connection is listening to the device's state changes, and that ends up in device_state_changed() in nm-vpn-connection.c.  Since the underlying device is being disconnected, the VPN disconnects itself with nm_vpn_connection_set_vpn_state(NM_VPN_CONNECTION_STATE_DISCONNECTED).  That triggers connection_vpn_state_changed() in nm-vpn-manager.c, which listens to VPN disconnection signals.  That re-emits the signal as CONNECTION_DEACTIVATED, which is picked up by nm-policy.c's vpn_connection_deactivated() which calls process_secondaries(), which then calls:

nm_device_state_changed (item_device, NM_DEVICE_STATE_FAILED, NM_DEVICE_STATE_REASON_SECONDARY_CONNECTION_FAILED);

because the VPN connection was still activating.  However, the device is already in the DISCONNECTED state by this point, although the signal has not yet been fully processed because the original call to nm_device_state_changed(DISCONNECTED) hasn't exited that function yet.

The easiest fix is probably something like this in process_secondaries():

+	if (nm_device_is_activating (item_device) || nm_device_get_state (item_device) == NM_DEVICE_STATE_ACTIVATED) {
		nm_device_state_changed (item_device, NM_DEVICE_STATE_FAILED,
				NM_DEVICE_STATE_REASON_SECONDARY_CONNECTION_FAILED);
+	}

Either that, or since the VPN connection disconnects itself with the reason code NM_VPN_CONNECTION_STATE_REASON_DEVICE_DISCONNECTED, perhaps process_secondaries() should somehow use that reason code and not change the device's state, since it's already being deactivated.

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.