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 703263 - Crash while freeing subscription data
Crash while freeing subscription data
Status: RESOLVED FIXED
Product: GUPnP
Classification: Other
Component: gupnp
unspecified
Other Linux
: Normal normal
: ---
Assigned To: GUPnP Maintainers
GUPnP Maintainers
: 705901 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-06-28 14:53 UTC by Jens Georg
Modified: 2013-10-16 13:08 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Do not try to reuse message on error (2.51 KB, patch)
2013-08-17 14:48 UTC, Jens Georg
committed Details | Review

Description Jens Georg 2013-06-28 14:53:45 UTC


  • #0 soup_session_cancel_message
    at soup-session.c line 1698
  • #1 subscription_data_free
    at gupnp-service.c line 159
  • #2 g_hash_table_remove_all_nodes
    at ghash.c line 500
  • #3 g_hash_table_remove_all
    at ghash.c line 1347
  • #4 gupnp_service_dispose
    at gupnp-service.c line 1598
  • #5 g_object_unref
    at gobject.c line 3157
  • #6 _vala_array_destroy
    at arraylist.c line 2194
  • #7 _vala_array_free
    at arraylist.c line 2202
  • #8 gee_array_list_finalize
    at arraylist.c line 2124
  • #9 g_object_unref
    at gobject.c line 3194
  • #10 rygel_root_device_finalize
    at /home/jens/Source/rygel/src/librygel-core/rygel-root-device.vala line 41
  • #11 g_object_unref
    at gobject.c line 3194
  • #12 _vala_array_destroy
    at arraylist.c line 2194
  • #13 _vala_array_free
    at arraylist.c line 2202
  • #14 gee_array_list_finalize
    at arraylist.c line 2124
  • #15 g_object_unref
    at gobject.c line 3194
  • #16 rygel_main_exit
    at /home/jens/Source/rygel/src/rygel/rygel-main.vala line 70
  • #17 __lambda3_
    at /home/jens/Source/rygel/src/rygel/rygel-main.vala line 63
  • #18 ___lambda3__gsource_func
    at rygel-main.c line 271
  • #19 g_unix_signal_watch_dispatch
    at gmain.c line 4942
  • #20 g_main_dispatch
    at gmain.c line 3058
  • #21 g_main_context_dispatch
    at gmain.c line 3634
  • #22 g_main_context_iterate
    at gmain.c line 3705
  • #23 g_main_loop_run
    at gmain.c line 3899
  • #24 rygel_main_run
    at /home/jens/Source/rygel/src/rygel/rygel-main.vala line 87
  • #25 rygel_main_main
    at /home/jens/Source/rygel/src/rygel/rygel-main.vala line 296
  • #26 main
    at /home/jens/Source/rygel/src/rygel/rygel-main.vala line 269

Comment 1 Jens Georg 2013-08-01 10:57:44 UTC
Another crash, not coming from Rygel:

  • #0 soup_session_cancel_message
    at soup-session.c line 1698
  • #1 subscription_data_free
    at gupnp-service.c line 159
  • #2 g_hash_table_remove_internal
    at ghash.c line 1276
  • #3 subscription_timeout
    at gupnp-service.c line 1127
  • #4 g_timeout_dispatch
    at gmain.c line 4443
  • #5 g_main_dispatch
    at gmain.c line 3058
  • #6 g_main_context_dispatch
    at gmain.c line 3634
  • #7 g_main_context_iterate
    at gmain.c line 3705
  • #8 g_main_loop_run
    at gmain.c line 3899
  • #9 rygel_main_run
    at /home/jens/Source/rygel/src/rygel/rygel-main.vala line 87
  • #10 rygel_main_main
    at /home/jens/Source/rygel/src/rygel/rygel-main.vala line 296
  • #11 main
    at /home/jens/Source/rygel/src/rygel/rygel-main.vala line 269

Comment 2 Jens Georg 2013-08-17 12:28:07 UTC
This seems to be reproducible ctrl-c-ing Rygel after running UDA-4.1.9, where the test issues a notify with an unresolvable hostname, which seems to leave an invalid soup message
Comment 3 Jens Georg 2013-08-17 12:51:58 UTC
Seems like it's not possible to requeue the message in this case and message is unreffed after leaving the callback, so we have a dangling pointer there.
Comment 4 Jens Georg 2013-08-17 14:48:16 UTC
Created attachment 252022 [details] [review]
Do not try to reuse message on error

If one of the call-backs has an error, just recreate the soup message. If we
want to re-use the old soup message we need to get the reference counting
right etc. This could lead to cases where notifications were not sent properly
because the first URL was failing and the requeuing failed as well.

Also it caused crashes by leaving a dangling pointer in pending_messages.
Comment 5 Jens Georg 2013-08-18 10:47:35 UTC
*** Bug 705901 has been marked as a duplicate of this bug. ***
Comment 6 Jens Georg 2013-10-16 13:07:57 UTC
Attachment 252022 [details] pushed as 00a73ff - Do not try to reuse message on error