GNOME Bugzilla – Bug 728139
avenc_aac deadlocks upon exit
Last modified: 2014-05-14 21:13:06 UTC
This pipeline seems to deadlock upon interrupting it with ^c gst-launch-1.0 -e audiotestsrc ! audioconvert ! avenc_aac compliance=-2 ! fakesink I tried the same pipeline with flacenc instead of avenc_aac and it does not deadlock. this is what valgrind shows: ==7510== Thread #1: Exiting thread still holds 2 locks ==7510== at 0x4B5C8D0: __lll_lock_wait (lowlevellock.c:49) ==7510== by 0x4B570A3: pthread_mutex_lock (pthread_mutex_lock.c:82) ==7510== by 0x483BF6B: pthread_mutex_lock (hg_intercepts.c:510) ==7510== by 0x514BA23: gst_audio_encoder_sink_activate_mode (gstaudioencoder.c:1977) ==7510== by 0x48B5007: gst_pad_activate_mode (gstpad.c:1083) ==7510== by 0x48B5B3B: gst_pad_set_active (gstpad.c:969) ==7510== by 0x48951F3: activate_pads (gstelement.c:2687) ==7510== by 0x48A675F: gst_iterator_fold (gstiterator.c:614) ==7510== by 0x489555B: iterator_activate_fold_with_resync.constprop.3 (gstelement.c:2707) ==7510== by 0x489789F: gst_element_pads_activate (gstelement.c:2751) ==7510== by 0x4897C0B: gst_element_change_state_func (gstelement.c:2815) ==7510== by 0x514BF73: gst_audio_encoder_change_state (gstaudioencoder.c:533) ==7510== ==7510== ---------------------------------------------------------------- ==7510== ==7510== Thread #2: Exiting thread still holds 4 locks ==7510== at 0x483D8F0: memcpy (hg_intercepts.c:2610) ==7510== by 0x575D2EB: psy_3gpp_analyze (aacpsy.c:750) ==7510== by 0x56EA8B7: aac_encode_frame (aacenc.c:599) ==7510== by 0x5648B8B: avcodec_encode_audio2 (utils.c:1001) ==7510== by 0x52F5437: gst_ffmpegaudenc_encode_audio (gstavaudenc.c:519) ==7510== by 0x52F5B53: gst_ffmpegaudenc_handle_frame (gstavaudenc.c:574) ==7510== by 0x514E763: gst_audio_encoder_push_buffers (gstaudioencoder.c:978) ==7510== by 0x51518BB: gst_audio_encoder_sink_event_default (gstaudioencoder.c:1487) ==7510== by 0x514B77F: gst_audio_encoder_sink_event (gstaudioencoder.c:1571) ==7510== by 0x48AEFB7: gst_pad_send_event_unchecked (gstpad.c:5035) ==7510== by 0x48AF7F7: gst_pad_push_event_unchecked (gstpad.c:4731) ==7510== by 0x48AFE27: push_sticky (gstpad.c:3370) ==7510==
seems that upon receiving EOS the encoder tries to encode/get the remaining data which then never finishes but I am not sure why and then gstaudioencoder deadlocks when it tries to deactivate the pad.
Created attachment 274221 [details] compressed log
This only happens on 1.2 branch, but not in master. And it looks the problem is in libav, since it continues to return encoded data even when not provided any new data (which makes higher layers think further draining is still needed). We could try to protect against such bogus codec behaviour, but given that it is fixed in master ...
*** This bug has been marked as a duplicate of bug 724536 ***