Opened 2 years ago

Closed 2 years ago

#8640 closed defect (needs_more_info)

Data race in pthread_frame.c and h264dec.c

Reported by: Zu-Ming Owned by:
Priority: normal Component: avcodec
Version: unspecified Keywords: h264 race
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


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.

Change History (4)

comment:1 by Carl Eugen Hoyos, 2 years ago

Keywords: h264 added; Data removed
Priority: importantnormal
Version: 4.2unspecified

How can I reproduce the issue?

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

comment:2 by Zu-Ming, 2 years ago

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.

comment:3 by Carl Eugen Hoyos, 2 years ago

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

comment:4 by Carl Eugen Hoyos, 2 years ago

Resolution: needs_more_info
Status: newclosed
Note: See TracTickets for help on using tickets.