Empty m3u8 after a Ctrl+C

[Gonzalo de Brito]

Summary of the bug:

In ffmpeg version 4.4, if we kill ffmpeg during a m3u8 copy process, sometimes the output m3u8 file results completly empty. During the copy process a cat on the file exhibits the expected content, but after the Ctrl+C the file results completly empty.

We couldn't reproduce this behaviour in ffmpeg v4.2.4, it seems to work perfectly fine in that version.

How to reproduce:

The command we're running is the following:

./ffmpeg_staging/ffmpeg -user_agent "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3554.0 Safari/537.36" -i <url> -c copy -f hls -hls_list_size 86400 -hls_flags delete_segments+append_list+program_date_time+temp_file -hls_segment_filename $segment_path $m3u8_path 

FFmpeg versions & builds:

This bug shows up in the following ffmpeg version, compiled from source:

ffmpeg version n4.4-10-g75c3969292 Copyright (c) 2000-2021 the FFmpeg developers
built with gcc 9 (Ubuntu 9.3.0-17ubuntu1~20.04)
configuration: --arch=amd64 --enable-gpl --enable-gnutls --enable-libx264 --toolchain=hardened --disable-stripping
libavutil      56. 70.100 / 56. 70.100
libavcodec     58.134.100 / 58.134.100
libavformat    58. 76.100 / 58. 76.100
libavdevice    58. 13.100 / 58. 13.100
libavfilter     7.110.100 /  7.110.100
libswscale      5.  9.100 /  5.  9.100
libswresample   3.  9.100 /  3.  9.100
libpostproc    55.  9.100 / 55.  9.100

We CAN'T reproduce this bug (works perfectly fine) in the following ffmpeg version, also compiled from source:

ffmpeg version 4.2.4 Copyright (c) 2000-2020 the FFmpeg developers
built with gcc 9 (Ubuntu 9.3.0-17ubuntu1~20.04)
configuration: --arch=amd64 --enable-gpl --enable-gnutls --enable-libx264 --toolchain=hardened --disable-stripping
libavutil      56. 31.100 / 56. 31.100
libavcodec     58. 54.100 / 58. 54.100
libavformat    58. 29.100 / 58. 29.100
libavdevice    58.  8.100 / 58.  8.100
libavfilter     7. 57.100 /  7. 57.100
libswscale      5.  5.100 /  5.  5.100
libswresample   3.  5.100 /  3.  5.100
libpostproc    55.  5.100 / 55.  5.100

Os: Ubuntu 20.04

If you need any further information, please ask me.
Best regards,
Gonzalo.-

[Carl Eugen Hoyos]

If you believe you found a regression please run git bisect to find the change introducing it.

[Gonzalo de Brito]

Dear Carl Eugen,

I did the git bisect, and i find out the commit in which the defect were introduced, it's the following one: 35eb5eeca809bc48463302dc29b5d46cd66e4a72

I tried to fix it, but my knowledge of signals it's quite basic, and i failed in the attempt.
Going back from sigaction() to signal(), fixes the problem (but, obviously, defeats the purpose of the commit)

If you need any further help, please ask me.
Best regards,
Gonzalo.-