pulsesink: Read access to the `device-name` property is not thread-safe
Describe your issue
While trying to debug a race condition in my application I created a smaller reproduction of my application. This application uses a lot of time.Sleep
in the cleanup (my reasoning was that a separate thread will run into a critical error if something is in the wrong order) and dumps the pipeline with gst_debug_bin_to_dot_file
after each step.
Expected Behavior
the App has a loop that starts 20 audio files consecutively, while only allowing 2 audios playing simultaneously.
The pipeline consists of a live audiomixer and an autoaudiosink. The inputs of the audiomixer are what I call a Source
, a bin containing the following: filesrc
, decodebin
, volume
, audioconvert
, pitch
, audioconvert
, audioresample
and queue
. Such a source is needed since the files will be cross faded at the mixer.
Each of these sources detects the end of the file via a pad probe and calls the cleanup function in a separate thread (as declared by the go func
keyword).
This cleanup function for the specific source disconnects the pads and removes the bin from the pipeline. Finally it removes all references to the elements and forces a GC, which makes the go bindings call unref
on the objects.
Observed Behavior
The pipeline runs and plays but after some time segfaults. This only happens when the export GST_DEBUG_DUMP_DOT_DIR=.
is set.
Setup
- Operating System: Arch Linux
- Device: Computer
- GStreamer Version: 1.22.6
Steps to reproduce the bug
- checkout the repo
- run
go run .
How reproducible is the bug?
Every time if export GST_DEBUG_DUMP_DOT_DIR=.
is set
If not set gstreamer logs multiple different:
(bug-repro:42190): GStreamer-CRITICAL **: 13:02:03.340:
Trying to dispose element filesrc1, but it is in PLAYING instead of the NULL state.
You need to explicitly set elements to the NULL state before
dropping the final reference, to allow them to clean up.
This problem may also be caused by a refcounting bug in the
application or some element.
Even though the state gets set to null before removing the element.
Additional Information
This might be a user error with the handling of the cleanup, but in any way I would not expect gstreamer to segfault.