GNOME Bugzilla – Bug 728153
Problem with send_lock when data in backlog and recive a teardown request.
Last modified: 2014-04-15 14:58:52 UTC
Created attachment 274230 [details] [review] gst-rtsp-server patch This when drop-backlog parameter is FALSE. The drop-backlog parameter is intruduced in ticket https://bugzilla.gnome.org/show_bug.cgi?id=725898 Attached file : gdb_bt Analyz: The handling of teardown Thread 3 (Thread 3111): stuck on mutex ownd by Thread 14 (Thread 3150): . That is stuck on mutex owned by Thread 15 (Thread 3151): We need to get out of do-while loop in do_send_message. The send_lock mutex taken in do_send_data will not be unlocked if loop not end. Solution: Inside do-while loop check if there is any transports, if not break the loop. Attached patch : breakloop.patch
Created attachment 274231 [details] gdb backtraces
checking for the transports seems wrong, the locking is not right and also the transports are removed in PAUSED, I think this patch is more correct (although the flushing is a little messy now) commit e69241ac975704cf99fa1f83cf167facbc913741 Author: Wim Taymans <wtaymans@redhat.com> Date: Tue Apr 15 16:51:17 2014 +0200 client: set the watch to flushing before going to NULL First set the watch to flushing so that we unblock any current and future attempt to send data on the watch, Then set the pipeline to NULL. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=728153