Data race in pthread_frame.c and h264dec.c

[Zu-Ming]

Summary of the bug:

Execute command: ./ffmpeg -y -threads 4 -i small.mp4 output.avi

Version: 4.2

Race object: p->got_frame

Thread 1:

Access: p->got_frame = 0;

Line number: pthread_frame.c; 537

Call stack:

1. ff_thread_decode_frame()
2. decode_simple_internal()
3. decode_simple_receive_frame()
4. decode_receive_frame_internal()
5. avcodec_send_packet()
6. decode()
7. decode_video()
8. process_input_packet()
9. process_input()
10. transcode_step()
11. transcode()
12. main()

Lock: None

Thread 2:

Access: *got_frame = 1;

Line number: h264dec.c; 913

Call stack:

1. finalize_frame()
2. h264_decode_frame()
3. frame_worker_thread()

Lock: pthread_mutex_lock(&p->mutex);

Impact: This race cause p->got_frame uncertain, which may affect the status of ffmpeg.

My data race fuzzer, conzzer, finds that these 2 accesses can be executed concurrently, and they are protected by different locks, so my fuzzer report this race.

[Carl Eugen Hoyos]

How can I reproduce the issue?

Please test current FFmpeg git head, the only version supported on this bug tracker.

[Zu-Ming]

Thanks for your response, cehoyos.

This race may be hard to reproduce. Actually, this race is detected by a lockset-based algorithm used in my fuzzer. This alogrithm doesn't need the race occurs really in the program. Instead, it uses some runtime information of the program to infer that there are some races in the program. So I just known there is a race in ffmpeg, but haven't idea for reproducing it. To confirm this race, I staitically check the code of ffmpeg, and I think it is a real race.

I test current FFmpeg git head, and I think the race is still alive.

[Carl Eugen Hoyos]

How would I (or another developer) know if the issue is fixed or still reproducible?