When using group connection and profiling, one of the reiceiver thread can reach 100% CPU comsuption
To Reproduce
- Build srt-xtransmit with the following configuration :
cmake ../ -DCMAKE_BUILD_TYPE=Release -DENABLE_ENCRYPTION=ON -DUSE_ENCLIB=openssl -DENABLE_BONDING=ON -DENABLE_PROFILE=ON
- Run xtransmit as follows :
./srt-xtransmit receive "srt://:4200?groupconnect=1" "srt://:5200?groupconnect=1"
./srt-xtransmit generate "srt://127.0.0.1:5200" "srt://127.0.0.1:4200" --sendrate 10Mbps
top -H -p receiver_pid
The bug is reproducible even faster using AES encryption. It however seems to be reproducible only in some environments, such as raspberry pi 2b using ubuntu 22.04.
Expected behavior
CPU should not reach 100%
Screenshots
Desktop (please provide the following information):
- OS: Ubuntu 24.04 LTS 64bit on raspberry pi 2b
- SRT Version / commit ID: cf13200 from Master (19/04/24)
Additional context
There seems to be a race condition of some sort. During my tests, I could see "deadlocks" happenning at random time, sometimes during the handshake process, sometimes when reading a packet, and so on. One example is shown in the attached results from perf.
Issue is more common at lower bitrate (faster to reproduce at 10mbps rather than 50mbps). It has not yet been observed in a production environment with profiling disabled.
When using group connection and profiling, one of the reiceiver thread can reach 100% CPU comsuption
To Reproduce
cmake ../ -DCMAKE_BUILD_TYPE=Release -DENABLE_ENCRYPTION=ON -DUSE_ENCLIB=openssl -DENABLE_BONDING=ON -DENABLE_PROFILE=ON./srt-xtransmit receive "srt://:4200?groupconnect=1" "srt://:5200?groupconnect=1"./srt-xtransmit generate "srt://127.0.0.1:5200" "srt://127.0.0.1:4200" --sendrate 10Mbpstop -H -p receiver_pidThe bug is reproducible even faster using AES encryption. It however seems to be reproducible only in some environments, such as raspberry pi 2b using ubuntu 22.04.
Expected behavior
CPU should not reach 100%
Screenshots
Desktop (please provide the following information):
Additional context
There seems to be a race condition of some sort. During my tests, I could see "deadlocks" happenning at random time, sometimes during the handshake process, sometimes when reading a packet, and so on. One example is shown in the attached results from perf.
Issue is more common at lower bitrate (faster to reproduce at 10mbps rather than 50mbps). It has not yet been observed in a production environment with profiling disabled.