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 728777 - bus: Holding object lock while unreffing messages can cause deadlocks
bus: Holding object lock while unreffing messages can cause deadlocks
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
unspecified
Other All
: Normal normal
: 1.4.6
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-04-23 08:15 UTC by Bastien Nocera
Modified: 2015-04-23 13:03 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Patch to fix this issue (1.35 KB, patch)
2015-03-13 13:33 UTC, Vivia Nikolaidou 		committed Details | Review

Description Bastien Nocera 2014-04-23 08:15:38 UTC 
When trying to play a NUT file, an error is thrown on the command-line, but the whole UI hangs:
http://samples.mplayerhq.hu/nut/
Comment 1 Patrick Welche 2014-12-07 18:44:57 UTC 
and CPU usage goes to 100%

My gdb doesn't seem to be happy enough to get more info "Couldn't get registers: No such process." when hitting ctl-c :-/
Comment 2 Bastien Nocera 2015-03-13 08:47:10 UTC 
Seems to be a problem with GStreamer 1.4.x, doesn't happen with the 1.5 branch:

+ Trace 234836

  • #0 syscall
    at ../sysdeps/unix/sysv/linux/x86_64/syscall.S line 38
  • #1 g_mutex_lock_slowpath
    at gthread-posix.c line 1308
  • #2 g_mutex_lock
    at gthread-posix.c line 1332
  • #3 gst_bus_post
    at gstbus.c line 312
  • #4 gst_element_post_message_default
    at gstelement.c line 1688
  • #5 gst_bin_post_message
    at gstbin.c line 2523
  • #6 _g_closure_invoke_va
    at gclosure.c line 831
  • #7 g_signal_emit_valist
    at gsignal.c line 3214
  • #8 g_signal_emit
    at gsignal.c line 3361
  • #9 g_cclosure_marshal_VOID__OBJECTv
    at gmarshal.c line 2102
  • #10 _g_closure_invoke_va
    at gclosure.c line 831
  • #11 g_signal_emit_valist
    at gsignal.c line 3214
  • #12 g_signal_emit
    at gsignal.c line 3361
  • #13 gst_element_remove_pad
    at gstelement.c line 804
  • #14 g_cclosure_marshal_VOID__OBJECTv
    at gmarshal.c line 2102
  • #15 _g_closure_invoke_va
    at gclosure.c line 831
  • #16 g_signal_emit_valist
    at gsignal.c line 3214
  • #17 g_signal_emit
    at gsignal.c line 3361
  • #18 gst_element_remove_pad
    at gstelement.c line 804
  • #19 gst_decode_chain_free_internal
    at gstdecodebin2.c line 2982
  • #20 gst_decode_group_free_internal
    at gstdecodebin2.c line 3101
  • #21 gst_decode_chain_free_internal
    at gstdecodebin2.c line 2896
  • #22 gst_decode_bin_dispose
    at gstdecodebin2.c line 3029
  • #23 gst_decode_bin_dispose
    at gstdecodebin2.c line 1109
  • #24 g_object_unref
    at gobject.c line 3133
  • #25 gst_object_unref
    at gstobject.c line 282
  • #26 _gst_message_free
    at gstmessage.c line 185
  • #27 gst_bus_set_flushing
    at ../gst/gstmessage.h line 364
  • #28 gst_bus_set_flushing
    at gstbus.c line 447
  • #29 gst_pipeline_change_state
    at gstpipeline.c line 506
  • #30 gst_play_bin_change_state
    at gstplaybin2.c line 5539
  • #31 gst_element_change_state
    at gstelement.c line 2602
  • #32 gst_element_set_state_func
    at gstelement.c line 2558
  • #33 bvw_bus_message_cb
  • #34 g_cclosure_marshal_VOID__BOXEDv
    at gmarshal.c line 1950
  • #35 _g_closure_invoke_va
    at gclosure.c line 831
  • #36 g_signal_emit_valist
    at gsignal.c line 3214
  • #37 g_signal_emit
    at gsignal.c line 3361
  • #38 gst_bus_async_signal_func
    at gstbus.c line 1131
  • #39 gst_bus_source_dispatch
    at gstbus.c line 775
  • #40 g_main_context_dispatch
    at gmain.c line 3122
  • #41 g_main_context_dispatch
    at gmain.c line 3737
  • #42 g_main_context_iterate
    at gmain.c line 3808
  • #43 g_main_context_iteration
    at gmain.c line 3869
  • #44 g_application_run
    at gapplication.c line 2308
  • #45 main 






Comment 3


Sebastian Dröge (slomo)





          2015-03-13 12:44:19 UTC
        



That's an interesting bug!

Flushing the bus takes the bus lock and frees a message, which then frees decodebin, which then posts a message on the exact same bus, trying to take the lock again.






Comment 4


Vivia Nikolaidou





          2015-03-13 13:33:38 UTC
        



Created attachment 299315 [details] [review]
Patch to fix this issue

The attached patch should fix the issue.






Comment 5


Sebastian Dröge (slomo)





          2015-03-13 13:41:19 UTC
        



commit f50d809c2548a3d2e067be81a94b96f4b6923f58
Author: Sebastian Dröge <sebastian@centricular.com>
Date:   Fri Mar 13 13:42:46 2015 +0000

    bus: Fix another case where we hold the object lock while unreffing a message

commit 721539dc4f029afff5b40b35b42b48874f025f64
Author: Vivia Nikolaidou <vivia@ahiru.eu>
Date:   Fri Mar 13 15:28:42 2015 +0200

    bus: Unreferencing messages outside the lock
    
    Shouldn't take the lock while unreferencing messages, because that may cause
    more messages to be sent, which will try to take the lock and cause the app to
    hang.
    
    Fixes https://bugzilla.gnome.org/show_bug.cgi?id=728777