After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 761655 - Crash in caps negotiation in presence of a tee
Crash in caps negotiation in presence of a tee
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: dont know
git master
Other Linux
: Normal blocker
: 1.7.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-02-06 23:07 UTC by Nicolas Dufresne (ndufresne)
Modified: 2016-02-10 11:59 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Nicolas Dufresne (ndufresne) 2016-02-06 23:07:25 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
Comment 1 Nicolas Dufresne (ndufresne) 2016-02-06 23:07:43 UTC
(This same pipeline works in 1.6)
Comment 2 Edward Hervey 2016-02-08 16:09:25 UTC
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==
Comment 3 Edward Hervey 2016-02-09 08:39:58 UTC
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).
Comment 4 Nicolas Dufresne (ndufresne) 2016-02-09 14:03:42 UTC
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).
Comment 5 Wim Taymans 2016-02-10 11:56:49 UTC
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