send_tcp_message race condition
in rtsp-stream in function send_tcp_message, we believe there is a small chance race condition can occur if the cache changes from another thread after n_outstanding have decreased to zero. The other thread can destroy the cache before the loop has ended.
We notice this in a test which repeatedly connects and disconnects crashes possibly due to this as back traces in gdb show us a corrupt GstRTSPStreamTransport object when calling one of the gst_rtsp_stream_transport_send_* functions.
This is one of the backtraces we have:
#0 0x76be528e in gst_rtsp_stream_transport_send_rtp_list (trans=trans@entry=0x1994908,
buffer_list=buffer_list@entry=0x75e2c908)
at ../../../gst-rtsp-server-1.16.0/gst/rtsp-server/rtsp-stream-transport.c:593
#1 0x76be0cc8 in send_tcp_message (stream=stream@entry=0x7181bb60, idx=<optimized out>)
at ../../../gst-rtsp-server-1.16.0/gst/rtsp-server/rtsp-stream.c:2537
#2 0x76be0e9e in send_thread_main (data=<optimized out>, user_data=0x7181bb60)
at ../../../gst-rtsp-server-1.16.0/gst/rtsp-server/rtsp-stream.c:2592
#3 0x76a0712c in g_thread_pool_thread_proxy (data=<optimized out>) at ../glib-2.60.5/glib/gthreadpool.c:308
#4 0x76a06a0e in g_thread_proxy (data=0x75ef2040) at ../glib-2.60.5/glib/gthread.c:805
#5 0x7684cac0 in start_thread (arg=0xe1741d2d) at pthread_create.c:486
#6 0x767ea8cc in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:73 from core/usr/lib/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) p *walk
$66 = {data = 0x1994908, next = 0x2, prev = 0x10000}
(gdb) p *tr
$67 = {parent = {g_type_instance = {g_class = 0x1}, ref_count = 0, qdata = 0x0}, priv = 0x80001, _gst_reserved = {
0x0, 0x1994978, 0x104, 0x19948f8}}The question is what shall be done about it? Shall we always use the mutex or shall we use a reference counted list instead?