GNOME Bugzilla – Bug 761655
Crash in caps negotiation in presence of a tee
Last modified: 2016-02-10 11:59:47 UTC
I didn't have time to figure-out today what's wrong, taking notes here. But it seems related to caps negotiation. Here's the pipeline to reproduce the crash: gst-launch-1.0 -v pulsesrc ! audio/x-raw,channels=1 ! tee name=t ! queue ! audioconvert ! spectrascope ! fakesink t. ! queue ! fakesink
(This same pipeline works in 1.6)
This seems to be related to a race within the audio conversion code. Valgrind gives me the following ==29726== Thread 4 pulsesrc0:src: ==29726== Invalid write of size 4 ==29726== at 0xF44B3BF: _backup_audio_orc_unpack_s16_trunc (tmp-orc.c:1154) ==29726== by 0xF44C3AA: audio_orc_unpack_s16_trunc (tmp-orc.c:1209) ==29726== by 0xF420509: do_unpack (audio-converter.c:432) ==29726== by 0xF4206B9: audio_chain_get_samples (audio-converter.c:237) ==29726== by 0xF4206B9: do_mix (audio-converter.c:478) ==29726== by 0xF41FC49: audio_chain_get_samples (audio-converter.c:237) ==29726== by 0xF41FC49: converter_generic (audio-converter.c:798) ==29726== by 0x14F11770: gst_audio_convert_transform (gstaudioconvert.c:743) ==29726== by 0xFD6DFE4: default_generate_output (gstbasetransform.c:2180) ==29726== by 0xFD703EE: gst_base_transform_chain (gstbasetransform.c:2333) ==29726== by 0x4EA41D1: gst_pad_chain_data_unchecked (gstpad.c:4155) ==29726== by 0x4EA41D1: gst_pad_push_data (gstpad.c:4407) ==29726== by 0x4EAC392: gst_pad_push (gstpad.c:4526) ==29726== by 0x14CEDEF1: gst_tee_do_push (gsttee.c:616) ==29726== by 0x14CEDEF1: gst_tee_handle_data (gsttee.c:696) ==29726== by 0x14CEE3B8: gst_tee_chain (gsttee.c:779) ==29726== Address 0x68a55f8 is 0 bytes after a block of size 920 alloc'd ==29726== at 0x4C28C50: malloc (vg_replace_malloc.c:298) ==29726== by 0x4C2AC1C: realloc (vg_replace_malloc.c:785) ==29726== by 0x590A59F: g_realloc (in /usr/lib64/libglib-2.0.so.0.4600.2) ==29726== by 0xF41FFE8: get_temp_samples (audio-converter.c:391) ==29726== by 0xF420417: audio_chain_alloc_samples (audio-converter.c:218) ==29726== by 0xF420417: do_unpack (audio-converter.c:424) ==29726== by 0xF4206B9: audio_chain_get_samples (audio-converter.c:237) ==29726== by 0xF4206B9: do_mix (audio-converter.c:478) ==29726== by 0xF41FC49: audio_chain_get_samples (audio-converter.c:237) ==29726== by 0xF41FC49: converter_generic (audio-converter.c:798) ==29726== by 0x14F11770: gst_audio_convert_transform (gstaudioconvert.c:743) ==29726== by 0xFD6DFE4: default_generate_output (gstbasetransform.c:2180) ==29726== by 0xFD703EE: gst_base_transform_chain (gstbasetransform.c:2333) ==29726== by 0x4EA41D1: gst_pad_chain_data_unchecked (gstpad.c:4155) ==29726== by 0x4EA41D1: gst_pad_push_data (gstpad.c:4407) ==29726== by 0x4EAC392: gst_pad_push (gstpad.c:4526) ==29726==
random thought : Since it doesn't happen without the tee/queue, I'm wondering if it's just not a case of using memory in-place ... which shouldn't be used in place (and therefore goes away).
Or the realloc that took place (probably caused by tee taking a ref) may have been done without any memory alignment (also a random thought).
commit 5cef3f31ad4454c2bf7cecbbb0e9b3d6dca60050 Author: Wim Taymans <wtaymans@redhat.com> Date: Wed Feb 10 12:48:15 2016 +0100 audio-converter: make a copy if we can't write in unpack If we don't have writable memory, make sure to make a copy of the input samples into a temporary (writable) buffer, even if we are dealing with a native intermediate format that we don't need to call the unpack function for. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=761655