NM currently uses the following code to poke ModemManager to ensure that it's started:

	g_connection = nm_dbus_manager_get_connection (priv->dbus_mgr);
	proxy = dbus_g_proxy_new_for_name (g_connection,
	 				   MM_DBUS_SERVICE,
	                                   MM_DBUS_PATH,
	                                   MM_DBUS_INTERFACE);
	dbus_g_proxy_call_no_reply (proxy, "EnumerateDevices", G_TYPE_INVALID);
	g_object_unref (proxy);

which causes the following crash:

[ 8160.978739] NetworkManager[3678]: #8  0x44b24b1f in __GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
[ 8160.990446] NetworkManager[3678]: #10 0x494b62df in g_assertion_message (domain=0x0, file=0x4973ea16 "dbus-gproxy.c", line=1058, func=0x4973f5a0 "dbus_g_proxy_manager_unregister", message=<optimized out>) at gtestutils.c:1425
[ 8161.042036] NetworkManager[3678]: #12 0x497347a2 in dbus_g_proxy_manager_unregister (manager=0x9969e30, proxy=0x9993b90 [DBusGProxy]) at dbus-gproxy.c:1058
[ 8161.046343] NetworkManager[3678]: #14 0x49588319 in g_object_unref (_object=0x9993b90) at gobject.c:2709
[ 8161.047711] NetworkManager[3678]: #16 0x080c91a9 in modem_manager_disappeared (self=0x998f800 [NMModemManager]) at nm-modem-manager.c:335
[ 8161.053489] NetworkManager[3678]: #22 0x080968a7 in nm_manager_init () at nm-manager.c:3494

due to presumably a race condition inside dbus-glib.  The crash in dbus_g_proxy_manager_unregister() corresponds to the following code:

  else
    {
      link = g_slist_find (manager->unassociated_proxies, proxy);
--->  g_assert (link != NULL);

      manager->unassociated_proxies = g_slist_delete_link (manager->unassociated_proxies, link);
    }

I think we can work around this in NM by not disposing of the proxy immediately, but waiting until the reply comes back...  but this is a crasher bug none-the-less.