Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • gst-rtsp-server gst-rtsp-server
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 94
    • Issues 94
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 8
    • Merge requests 8
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GStreamerGStreamer
  • gst-rtsp-servergst-rtsp-server
  • Issues
  • #81
Closed
Open
Issue created Sep 18, 2019 by johanadamnilsson@johanadamnilssonReporter

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?

Edited Sep 30, 2019 by johanadamnilsson
Assignee
Assign to
Time tracking