| Summary: | Crash when calling method on unassociated proxy then disposing of it | ||
|---|---|---|---|
| Product: | dbus | Reporter: | Dan Williams <dcbw> |
| Component: | GLib | Assignee: | Rob Taylor <rob.taylor> |
| Status: | RESOLVED DUPLICATE | QA Contact: | John (J5) Palmieri <johnp> |
| Severity: | normal | ||
| Priority: | medium | CC: | smcv, william.jon.mccann |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
Hmm, I suppose I assumed that dbus-glib would take a reference to the DBusGProxy over any calls, until the call completed. Is that not the case? Seems like nothing does, I can't find anything in dbus_g_proxy_call_no_reply() that refs the proxy. If it's the case that proxies are not kept alive by internal references over calls, then please close this bug as INVALID. I've fixed up NetworkManager in any case. Relevant NM fix: c9119c759956852a1f35a2fc36fb460d54ab97ad This should have been fixed in 0.96 (Bug #38408), which version were you using? Do you have a standalone, compilable test case for this? If not, I'll write one based on your code snippet. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
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.