GStreamer rtspclientsink element experienced a segfault in libgstrtsp-1.0.so in write_bytes()
Describe your issue
We're trying to start a GStreamer pipeline using C++ libraries, in which we start it through a JNI interface from a Scala application. The initiated pipeline sometimes causes a segfault which as a result crashes the JVM entirely and makes the entire application unavailable for other pipelines to run or even allows existing ones to continue running.
Expected Behavior
The strive is not having the behavior of segfault. Of course, as might already be known, a segfault can be prevented only when finding the memory leak issue core origin problem which can be wrong applicative use or implementation, but in general, the expected behavior is basically not experiencing segfault from the first place.
Observed Behavior
The use of the rtspclientsink element, in some cases, causes a segfault for the library "libgstrtsp.so" in the function call write_bytes().
Setup
- Operating System: Docker container based on Ubuntu OS 18.04.
- Device: AWS EC2 Instance(Ubuntu OS 18.04) running a Docker.
- GStreamer Version: 1.18.4
- Command line: Ran as part of GStreamer shared libraries in C++ shared library project.
Steps to reproduce the bug
- Create a GStreamer C++ based app using v1.18.4.
- In the built pipeline string for the GStreamer API in C++ that does the following - read PCMA/PCMU RTP data of audio, mixes them to a single audio stream, encode it with AAC codec, and send it via rtspclientsink to a MediaServer like Wowza for example.
How reproducible is the bug?
The bug doesn't occur in high frequency, and does not necessarily have a strict pattern to allow indicating the source of the issue, unfortunately.
Screenshots if relevant
Don't have any.
Solutions you have tried
Can't do any solution due to being an internal issue of GStreamer as it seems.
Related non-duplicate issues
Didn't find any.
Additional Information
I have the crash report, but don't wish for the code signature or anything be visible to anyone who sees this ticket, so either we make it confidential or please tell which parts of the JVM crash reports are needed to further investigate the problem.
Of course, tell me what is easier and I'll provide as asked