Data race in pthread_frame.c

[Zu-Ming]

Summary of the bug:

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

Version: 4.2

Race object: p->result

Thread 1:

Access: p->result = codec->decode(avctx, p->frame, &p->got_frame, &p->avpkt);

Line number: pthread_frame.c; 201

Call stack:

1. frame_worker_thread()

Lock: pthread_mutex_lock(&p->mutex);

Thread 2:

Access: p->result = 0;

Line number: h264dec.c; 913

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. transcode()
10. main()

Lock: None

Impact: This race cause p->result 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 using 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 race 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.