srt: [BUG] SIGSEGV while receiving broadcast group stream.
Describe the bug SIGSEGV in buffer.cpp while receiving stream over broadcast group. No network impairment added. Gdb session with log trace added.
To Reproduce aarch64 test app caller/receiver runs on MX4D to receive MX4E listener/sender stream configured with 2 paths on 2 NICs.
{ 1}srt clnt rx Broadcast link bonding STREAMING none evcb
{ 1:1}srt 10.65.10.230:34082|10.65.10.234:9972 1.4.4 STREAMING none evcb
{ 1:2}srt 192.168.10.230:6272|192.168.10.234:9972 1.4.4 STREAMING none evcb
{ 2}srt lstn tx { 1} > srt://9955
0.0.0.0:9955| LISTENING none none
{ 4}srt lstn tx { 1} > srt://9956
0.0.0.0:9956|
runs smoothly for ~100 min. receiving 1.5 Mbps CNN.
libsrt from branch fix-binding-any of my fork, based on 1.4.4.rc1 with fixes in api.cpp (one uncommitted fix to push).
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 31 (2 by maintainers)
Commits related to this issue
- Merge branch 'master' into fix-binding-any Grab PRs fixing issue #2133 — committed to jeandube/srt by jeandube 2 years ago
I was thinking about it, but the problem here is that its role is to trigger appropriate flags at the strictly specified time and doing it in a thread that is also doing other things in the meantime may lose some accuracy. Might be that receiver-dropping shall be simply done differently, possibly by allowing the reader to step on empty units when packets are lacking and simply skip them when retrieveing the data.
What is important, is that in this exactly place the problem is likely fixable by adding the same mutex that is used in the main thread’s call.
Reproduced while receiving non-group stream. Problem seems to be having different threads pulling data (srt_rcvmsg2()) and pulling stats (srt_bstats()). srt_bstats() gets RcvBuffer size and timespan and can have the m_pUnit[X] it is handling get freed by the data pulling thread, causing SIGSEGV on NULL pointer. RcvBuffer is not thread safe. From the public API it seems restricted to srt_bstats() and the like vs. srt_recvXxx, but internally, many CRcvBuffer public methods have vulnerable code sections. If not fixed in the SRT lib this should at least be documented. Again the RcvBuffer state was not part of the stats in the original UDT design.
It is clear that TSBPD thread has been implemented without a clear understanding of the UDT threading model and intrinsic protection that comes with it. Who other than me can say this 😃 Now it’s done. The TSBPD code should probably be run in the SRT:RcvQ thread, removing the need of many mutexes we keep adding to work around this design flaw.