After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 747721 - Issue when Service lives longer than RootDevivce
Issue when Service lives longer than RootDevivce
Product: GUPnP
Classification: Other
Component: gupnp
Other Linux
: Normal normal
: ---
Assigned To: GUPnP Maintainers
GUPnP Maintainers
Depends on:
Blocks: 750730
Reported: 2015-04-11 22:59 UTC by Jens Georg
Modified: 2021-05-17 16:30 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Jens Georg 2015-04-11 22:59:47 UTC
If the GUPnPRootDevice belonging to a GUPnPService is taken down before the GUPnPService, the weak reference will properly NULLify root_device in GUPnPServicePrivate but element in GUPnPServiceInfoPrivate will point to a dangling pointer leading to a crash in gupnp_service_info_dispose:

==3849== Invalid read of size 8
==3849==    at 0x4E56D1D: xml_util_get_element (xml-util.c:43)
==3849==    by 0x4E56D8C: xml_util_get_child_element_content (xml-util.c:62)
==3849==    by 0x4E56E4D: xml_util_get_child_element_content_uri (xml-util.c:115)
==3849==    by 0x4E56EAA: xml_util_get_child_element_content_url (xml-util.c:137)
==3849==    by 0x4E4BA99: gupnp_service_dispose (gupnp-service.c:1577)
==3849==    by 0x56CE184: g_object_unref (gobject.c:3137)
==3849==    by 0x15C18A4C: block3_data_unref (rygel-av-transport.vala:872)
==3849==    by 0x56C891F: closure_invoke_notifiers (gclosure.c:241)
==3849==    by 0x56C891F: g_closure_unref (gclosure.c:590)
==3849==    by 0x56E20E1: handler_unref_R (gsignal.c:637)
==3849==    by 0x56E20E1: g_signal_handlers_destroy (gsignal.c:2641)
==3849==    by 0x56CD82C: g_object_real_dispose (gobject.c:1019)
==3849==    by 0x56CE184: g_object_unref (gobject.c:3137)
==3849==    by 0x6BFC590: soup_message_queue_item_unref (soup-message-queue.c:186)
==3849==    by 0x6BFC732: soup_message_queue_next (soup-message-queue.c:283)
==3849==    by 0x6C0B6DB: async_run_queue (soup-session.c:2095)
==3849==    by 0x6C0B813: idle_run_queue (soup-session.c:2140)
==3849==    by 0x5955E5C: g_main_dispatch (gmain.c:3122)
==3849==    by 0x5955E5C: g_main_context_dispatch (gmain.c:3737)
==3849==    by 0x595622F: g_main_context_iterate.isra.29 (gmain.c:3808)
==3849==    by 0x5956551: g_main_loop_run (gmain.c:4002)
==3849==    by 0x405B57: rygel_main_run (rygel-main.vala:89)
==3849==    by 0x408BF5: rygel_main_main (rygel-main.vala:304)
==3849==  Address 0x105b6208 is 24 bytes inside a block of size 120 free'd
==3849==    at 0x4C2BE10: free (vg_replace_malloc.c:473)
==3849==    by 0x6EC1C0F: xmlFreeNodeList (in /usr/lib/x86_64-linux-gnu/
==3849==    by 0x6EC1C4D: xmlFreeNodeList (in /usr/lib/x86_64-linux-gnu/
==3849==    by 0x6EC1C4D: xmlFreeNodeList (in /usr/lib/x86_64-linux-gnu/
==3849==    by 0x6EC1C4D: xmlFreeNodeList (in /usr/lib/x86_64-linux-gnu/
==3849==    by 0x6EC19C5: xmlFreeDoc (in /usr/lib/x86_64-linux-gnu/
==3849==    by 0x4E53B8C: gupnp_xml_doc_finalize (gupnp-xml-doc.c:56)
==3849==    by 0x56CE1F9: g_object_unref (gobject.c:3174)
==3849==    by 0x4E4A1A7: gupnp_root_device_finalize (gupnp-root-device.c:68)
==3849==    by 0x5E82215: rygel_root_device_finalize (rygel-root-device.vala:40)
==3849==    by 0x56CE1F9: g_object_unref (gobject.c:3174)
==3849==    by 0x50822FB: gee_array_list_iterator_real_remove (arraylist.c:2745)
==3849==    by 0x40737F: rygel_main_on_context_unavailable (rygel-main.vala:203)
==3849==    by 0x406156: _rygel_main_on_context_unavailable_gupnp_context_manager_context_unavailable (rygel-main.vala:146)

We currently have added a work-around for this bug in Rygel, but it is butt-ugly (
Comment 1 Jens Georg 2015-04-11 23:05:18 UTC
We cannot simply make element a week pointer to the root device, otherwise we cannot remove our handlers from the context which might live way longer than the root device
Comment 2 Jens Georg 2016-09-30 14:46:21 UTC
For service proxies it's actually just working by accident since we are leaking the description document.
Comment 3 Jens Georg 2016-09-30 14:48:08 UTC
(In reply to Jens Georg from comment #2)
> For service proxies it's actually just working by accident since we are
> leaking the description document.

Actually, that's still just services
Comment 4 Jens Georg 2016-09-30 14:49:35 UTC
If you didn't pass the description document externally, it actually leaked so that's why it didn't show
Comment 5 GNOME Infrastructure Team 2021-05-17 16:30:31 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: