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 694418 - double free after bd07f714 "Add a function doing a service rescan"
double free after bd07f714 "Add a function doing a service rescan"
Status: RESOLVED FIXED
Product: gssdp
Classification: Other
Component: General
unspecified
Other Linux
: Normal normal
: ---
Assigned To: GUPnP Maintainers
GUPnP Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-02-22 08:05 UTC by Jussi Kukkonen
Modified: 2019-02-22 09:29 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Use g_hashtable_add() instead of g_hash_table_insert() (1.30 KB, patch)
2013-02-22 08:47 UTC, Jussi Kukkonen 		committed Details | Review

Description Jussi Kukkonen 2013-02-22 08:05:23 UTC 
I just updated to 0.14.0 and can reproduce the following crash very easily, (just by starting dleyna media-service-upnp). I can see several ResourceBrowsers being created, and then after 5 secs when refresh_cache() gets called, bad things often (but not always) happen on one of them. The backtrace is typical but not the only one I've seen.

It started with commit bd07f714386, although I'm not totally sure how this happens...

I've not updated the other components yet so gupnp is 0.19.4.

+ Trace 231543

  • #0 raise
    from /lib/x86_64-linux-gnu/libc.so.6
  • #1 abort
    from /lib/x86_64-linux-gnu/libc.so.6
  • #2 ??
    from /lib/x86_64-linux-gnu/libc.so.6
  • #3 ??
    from /lib/x86_64-linux-gnu/libc.so.6
  • #4 free
    from /lib/x86_64-linux-gnu/libc.so.6
  • #5 g_hash_table_remove_all_nodes
    at /tmp/buildd/glib2.0-2.33.12+really2.32.4/./glib/ghash.c line 533
  • #6 g_hash_table_unref
    at /tmp/buildd/glib2.0-2.33.12+really2.32.4/./glib/ghash.c line 1024
  • #7 refresh_cache
    at gssdp-resource-browser.c line 1170
  • #8 g_timeout_dispatch
    at /tmp/buildd/glib2.0-2.33.12+really2.32.4/./glib/gmain.c line 3882
  • #9 g_main_dispatch
    at /tmp/buildd/glib2.0-2.33.12+really2.32.4/./glib/gmain.c line 2539
  • #10 g_main_context_dispatch
    at /tmp/buildd/glib2.0-2.33.12+really2.32.4/./glib/gmain.c line 3075
  • #11 g_main_context_iterate
    at /tmp/buildd/glib2.0-2.33.12+really2.32.4/./glib/gmain.c line 3146
  • #12 g_main_loop_run
    at /tmp/buildd/glib2.0-2.33.12+really2.32.4/./glib/gmain.c line 3340 






Comment 1


Krzesimir Nowak





          2013-02-22 08:17:03 UTC
        



I suppose I'll have to replace the g_hash_table_insert with g_hash_table_replace. There was some issue with the former function fixed in GLib-2.35.6 (http://git.gnome.org/browse/glib/commit/?id=bb1df4d01b25e6e12ff30adcd3b07b37c4837bc0). I guess you are not using the bleeding-edge GLib as it wasn't backported into stable 2.34 or 2.32 branches.






Comment 2


Jussi Kukkonen





          2013-02-22 08:26:39 UTC
        



Good catch. I'm on Debian unstable (8 months in release freeze now) so definitely not bleeding edge: glib is 2.34.

I can test this since it's so easy for me to reproduce, just a minute....






Comment 3


Jussi Kukkonen





          2013-02-22 08:47:51 UTC
        



Created attachment 237148 [details] [review]
Use g_hashtable_add() instead of g_hash_table_insert()

Yep, you are correct. Attaching a patch that fixes this for me.






Comment 4


Krzesimir Nowak





          2013-02-22 09:40:34 UTC
        



Fixed. Bumped GLib dep to 2.32.