osxaudiosink: Pitch element causes pipeline failures and crashes when used with autoaudiosink

Submitted by Sjors Gielen

Link to original bug (#753147)

Description

Created attachment 308627
Output of the Address Sanitizer

The pitch element, part of the soundtouch plugin in gst-plugins-bad, seems to be causing pipeline failures and even crashes in some pipelines on Mac OS X when used together directly with the autoaudiosink. Address Sanitizer detects "heap use after free" or segmentation fault on various addresses in some pipelines as well. I have not yet extensively debugged the issue, but have tried to grasp the scope of it below.

This is tested using GStreamer 1.4.5 on Mac OS X 10.10.4. The GStreamer core package and gst-plugins-bad were built by Homebrew, with two manual changes, one to build Soundtouch and one to enable Address Sanitizer by building with GCC 5.2.0 and adding -fsanitize=address. I have yet to rebuild gst-plugins-{base,good} with ASAN and will also enable debugging symbols so I can provide more debugging information.

I believe the simplest command that should succeed but causes an internal data flow error is the following:

----8<----
$ gst-launch-1.0 audiotestsrc ! pitch ! autoaudiosink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /GstPipeline:pipeline0/GstAudioTestSrc:audiotestsrc0: Internal data flow error.
Additional debug info:
gstbasesrc.c(2933): gst_base_src_loop (): /GstPipeline:pipeline0/GstAudioTestSrc:audiotestsrc0:
streaming task paused, reason not-negotiated (-4)
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...
---->8----

This command succeeds on my Linux test machine (a test sound is audible). On OS X, the problem seems gone when adding an audioconvert as well:

----8<----
$ gst-launch-1.0 audiotestsrc ! pitch ! audioconvert ! autoaudiosink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Redistribute latency...
[...]
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstAudioSinkClock
Redistribute latency...
[...]
---->8----

Also, the following similar command without audioconvert does succeed on this OS X machine:

----8<----
$ gst-launch-1.0 audiotestsrc ! pitch ! filesink location=/dev/null
(similar output to above)
---->8----

The simplest command that should succeed but instead triggers the Address Sanitizer is the following (ASAN output replaced with output from asan_symbolize). Note that it does not trigger this exact error in all cases; in others, it causes a pipeline error similar to the above one, or a different kind of ASAN error, which leads me to suspect a race condition...

----8<----
$ gst-launch-1.0 filesrc location=../jg.mp3 ! mad ! audioconvert ! pitch ! autoaudiosink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /GstPipeline:pipeline0/GstFileSrc:filesrc0: Internal data flow error.
Additional debug info:
gstbasesrc.c(2933): gst_base_src_loop (): /GstPipeline:pipeline0/GstFileSrc:filesrc0:
streaming task paused, reason not-negotiated (-4)
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...

==90797==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200002bef0 at pc 0x000108abc405 bp 0x00010ed86bc0 sp 0x00010ed86370
[...]
---->8----

The full output of the ASAN symbolizer is attached to this bug report for brevity. Like above, this error does not occur when adding an audioconvert, or when using a filesink or fakesink.

----8<----
$ gst-launch-1.0 filesrc location=../jg.mp3 ! mad ! audioconvert ! pitch ! audioconvert ! autoaudiosink
(similar output to succesful runs above)
---->8----

I will try to add information to this bug report as I go. I would appreciate it if others could repeat my experiments and confirm my findings. Thank you!

Attachment 308627, "Output of the Address Sanitizer":
asan_output.txt

Version: 1.4.5