[BUG]crashed on ubuntu22.04.02 when exit

[xengine-qyt]

Describe the bug
crashed on ubuntu 22.04 when program exit.it is appears every time

To Reproduce
ubuntu22.04.02 lts
sudo apt install libavcodec-dev libavdevice-dev libavfilter-dev libavformat-dev libswresample-dev libswscale-dev libsrt-openssl-dev -y

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
extern "C"
{
#include <libavcodec/avcodec.h>
#include <libavdevice/avdevice.h>
#include <libavfilter/avfilter.h>
#include <libavformat/avformat.h>
#include <libavutil/dict.h>
#include <libavutil/avutil.h>
#include <libavutil/imgutils.h>
#include <libswresample/swresample.h>
#include <libswscale/swscale.h>
}
#include <srt/srt.h>

int main()
{
avformat_network_init();
avdevice_register_all();

srt_startup();
srt_setloglevel(srt_logging::LogLevel::error);


return 0;

}

complie:g++ -std=c++17 -Wall -g a.cpp -o out.app -lsrt -lavcodec -lavdevice -lavfilter -lavformat -lavutil -lswresample -lswscale -lpthread -lrt -ldl

[maxsharabayko]

Please remove libav, keep only SRT, and try to see if the crash is still there.

[xengine-qyt]

It will appear when ffmpeg and srt library are used together, and there is no problem when used alone

[maxsharabayko]

I would recommend checking if those resources need to be closed / unregistered.

avformat_network_init();
avdevice_register_all();

[xengine-qyt]

they are does not need to release resources .

[maxsharabayko]

What if you add srt_cleanup() in the end?

[xengine-qyt]

it is same too.

[xengine-qyt]

I think it is caused by a conflict with ffmpeg, because there will be no problem under windows, and I have not tried the compiled version on ubuntu

[xengine-qyt]

if you have ubuntu 22.04 x64 ,you can test for it

[maxsharabayko]

Does it crash without avdevice_register_all()?

[ethouris]

The only place where CUDTUnited::~CUDTUnited() could crash is delete m_pCache. Everything else is in different functions and releaseMutex is an empty call.

Would you be able to modify the code or at least read the debug info? This could theoretically happen on any kind of double delete, even if unlikely.

[xengine-qyt]

Does it crash without avdevice_register_all()?

not crash,crahed only when used with ffmpeg library

[xengine-qyt]

The only place where CUDTUnited::~CUDTUnited() could crash is delete m_pCache. Everything else is in different functions and releaseMutex is an empty call.

Would you be able to modify the code or at least read the debug info? This could theoretically happen on any kind of double delete, even if unlikely.

apt install srt and ffmpeg,i can't read debug info

[maxsharabayko]

Incompatible versions? Note that SRT has API/API changes in minor releases, e.g. 1.5.0, 1.4.0, etc.

[xengine-qyt]

maybe,i am not tried compiled for srt,i will try later

[maxsharabayko]

Please tell us the versions of SRT and FFmpeg installed on your system by apt.

[xengine-qyt]

ffmpeg:4.4.2
libsrt:1.4.4

[yomnes0]

I reproduced the crash on ubuntu 22.04 with srt and ffmpeg from apt-get.
I couldn't get debug info from the BT since packages were installed through apt-get. I however ran the exact same test with ffmpeg and srt built from sources and It doesn't crash. It looks like an incompatibility between SRT 1.4.4 and ffmpeg 4.4.2

[ethouris]

You might also recompile SRT 1.4.4 and check again. I remember there were some problems, related to logs, which caused crashing if the internals were destroyed in wrong order, but I don't recall which version had it fixed.

[maxsharabayko]

SRT package in Ubuntu 22.04
https://packages.ubuntu.com/source/jammy/srt

avdevice_register_all()
https://ffmpeg.org/doxygen/1.2/alldevices_8c_source.html#l00040

@florianernst FYI.

[yomnes0]

Using the srt source fetched from the link provided by @maxsharabayko , it doesn't crash. Next up, rebuilding the version of ffmpeg used by ubuntu 22.04

[xengine-qyt]

I tried 1.4.4 and 1.5.2 versions, is the same too.

[ethouris]

Is that possible to get a debug-instrumented backtrace on this crash? If you can recompile SRT in a certain version and still reproduce it, use -DENABLE_DEBUG=2 to get the debug-optimized version, or simply -DENABLE_DEBUG=1 to get the full debug version.

[florianernst]

@maxsharabayko, thanks for the ping. :-)

@xengine-qyt, please install libsrt-gnutls-dev instead (doing so will automatically remove libsrt-openssl-dev) and then compile using -lsrt-gnutls (instead of -lsrt).
Or at least that's what helped me locally, both on Debian stable "bookworm" (newer than Ubuntu 22.04) and Debian oldstable "bullseye" (older than Ubuntu 22.04): with the openssl variant I could reproduce your segfault, but with the gnutls variant no errors occurred. I cannot fully tell for Ubuntu, though, as I am not directly involved with them (Ubuntu takes the packages from Debian, at a certain time, and sometimes applies additional modifications, and I only deal with the Debian side of things).

It looks like something in the software dependency chain is also using GnuTLS instead of OpenSSL, and attempting mix those leads to such a crash as you have encountered. I believe this is FFmpeg, but I cannot check right now. This would also explain why those people who have compiled the software themselves locally didn't encounter the issues, as for them there most presumably is no such mixing taking place.

Just for reference, in Debian there exist two variants of srt: one linked against GnuTLS, which is what is mostly used there, and one linked against OpenSSL. These two exist for licensing reasons, please cf. https://bugs.debian.org/933180 for some background information.

Thus I'm wondering whether it makes sense to make the GnuTLS variant of srt the default in Debian, but I haven't even at the slightest investigated how much effort that would be ...

[yomnes0]

Using SRT 1.4.4 and ffmpeg 4.4.2, both compiled locally, I can't reproduce the crash. This goes along with @florianernst analysis

[xengine-qyt]

@maxsharabayko, thanks for the ping. :-)

@xengine-qyt, please install libsrt-gnutls-dev instead (doing so will automatically remove libsrt-openssl-dev) and then compile using -lsrt-gnutls (instead of -lsrt). Or at least that's what helped me locally, both on Debian stable "bookworm" (newer than Ubuntu 22.04) and Debian oldstable "bullseye" (older than Ubuntu 22.04): with the openssl variant I could reproduce your segfault, but with the gnutls variant no errors occurred. I cannot fully tell for Ubuntu, though, as I am not directly involved with them (Ubuntu takes the packages from Debian, at a certain time, and sometimes applies additional modifications, and I only deal with the Debian side of things).

It looks like something in the software dependency chain is also using GnuTLS instead of OpenSSL, and attempting mix those leads to such a crash as you have encountered. I believe this is FFmpeg, but I cannot check right now. This would also explain why those people who have compiled the software themselves locally didn't encounter the issues, as for them there most presumably is no such mixing taking place.

Just for reference, in Debian there exist two variants of srt: one linked against GnuTLS, which is what is mostly used there, and one linked against OpenSSL. These two exist for licensing reasons, please cf. https://bugs.debian.org/933180 for some background information.

Thus I'm wondering whether it makes sense to make the GnuTLS variant of srt the default in Debian, but I haven't even at the slightest investigated how much effort that would be ...

it does not crash when i using libsrt-gnutls-dev instead of libsrt-openssl-dev.thanks.