[FFmpeg-devel] [bisected] Crashing Firefox

[James Almer]

On 8/23/2018 2:34 PM, Mohammad_AlSaleh wrote:
> On Fri, Aug 17, 2018 at 12:07:56AM -0300, James Almer wrote:
>> On 7/28/2018 6:28 PM, Michael Niedermayer wrote:
>>> On Sat, Jul 28, 2018 at 01:25:36PM -0300, James Almer wrote:
>>>> On 7/28/2018 4:09 AM, Michael Niedermayer wrote:
>>>>> On Fri, Jul 27, 2018 at 11:11:47PM -0300, James Almer wrote:
>>>>>> On 7/27/2018 10:58 PM, Michael Niedermayer wrote:
>>>>>>> On Fri, Jul 27, 2018 at 11:57:49AM -0300, James Almer wrote:
>>>>>>>> Certain AVCodecParameters, like the contents of the extradata, may be changed
>>>>>>>> by the init() function of any of the bitstream filters in the chain.
>>>>>>>>
>>>>>>>> Signed-off-by: James Almer <jamrial at gmail.com>
>>>>>>>> ---
>>>>>>>> Now it's not going to be called after the codec has been opened.
>>>>>>>>
>>>>>>>>  libavcodec/decode.c | 4 ++++
>>>>>>>>  1 file changed, 4 insertions(+)
>>>>>>>
>>>>>>> This breaks:
>>>>>>> ffmpeg -i https://upload.wikimedia.org/wikipedia/commons/1/14/Animated_PNG_example_bouncing_beach_ball.png -bitexact -pix_fmt rgba -f framecrc -
>>>>>>
>>>>>> Is any other decoder failing the same way? Because the apng decoder
>>>>>> threading code may be faulty otherwise. Plenty of avctx fields are
>>>>>> changed after ff_thread_init() is called within avcodec_open2(). There
>>>>>> should not be a race at this point.
>>>>>
>>>>> I found a failure with mpeg4 (with bframes) decoding + pcm_alaw from mkv but it
>>>>> does not want to reproduce. The slightest change i do makes this not happen
>>>>> even just duplicating a command line parameter (which should have no effect)
>>>>> simply adding the -threads parameter to it independant of value makes it go away
>>>>> too
>>>>>
>>>>>
>>>>> in the png case
>>>>> this hits teh issue:
>>>>> -threads 2 -i https://upload.wikimedia.org/wikipedia/commons/1/14/Animated_PNG_example_bouncing_beach_ball.png  -f framecrc -
>>>>>
>>>>> this does not:
>>>>> -threads 1 -i https://upload.wikimedia.org/wikipedia/commons/1/14/Animated_PNG_example_bouncing_beach_ball.png  -f framecrc -
>>>>>
>>>>> also odly the bitexact flag made a differnce in how it fails outside valgrind
>>>>> last i tried. (doesnt make a difference in valgrind it seems)
>>>>
>>>> A solution may be moving the ff_decode_bsfs_init call in patch 7/8 right
>>>> above the call to ff_thread_init (See attachment), hopefully preventing
>>>> this race once this patch is applied afterwards, but it will result in
>>>> the bsfs initialized before the decoder, and some of the avctx fields
>>>> that are changed later in avcodec_open2 like channels and bit_rate not
>>>> being reflected during said bsfs initialization.
>>>> I can't say if the former is correct or ideal, but for now the latter
>>>> would not be an issue. I don't know what may happen if we were to
>>>> autoinsert a filter that does care about such fields in the future, though.
>>>>
>>>> If the above change doesn't solve it, or is not ideal, then this patch
>>>> 8/8 can be dropped or postponed, and the rest of the set pushed without it.
>>>
>>> with this patch, the pachset seems not to trigger these errors anymore
>>>
>>> thanks
>>
>> Set pushed. Thanks.
>>
> 
> Just so you know, f631c328e680a3dd491936b92f69970c20cdcfc7
> causes Firefox's media playback thread to crash.
> 
> Just try playing any local or remote mp4 file. The crash is
> reproducible.
> 
> Tested and bisected with FF Developer Edition (64-bit linux).

Can you give us some more details, and a gdb output?

And please open a ticket in http://trac.ffmpeg.org/ for this.