[FFmpeg-trac] #8669(avcodec:new): Data race in mpegvideo.c and mpeg4video.h

[FFmpeg]

#8669: Data race in mpegvideo.c and mpeg4video.h
---------------------------------+--------------------------------------
             Reporter:  Zu-Ming  |                     Type:  defect
               Status:  new      |                 Priority:  normal
            Component:  avcodec  |                  Version:  git-master
             Keywords:  race     |               Blocked By:
             Blocking:           |  Reproduced by developer:  0
Analyzed by developer:  0        |
---------------------------------+--------------------------------------
 **Note:** To prove the data race is real, I set breakpoints before these
 two access when they are running in the call stacks described below. I
 find that the breakpoints can be activated simultaneously, and the
 addresses of race variables are same. I think these result can prove that
 the race is real.

 **Summary of the race**

 Execute command: `./ffmpeg -y -threads 4 -i small.mp4 output.avi`
 Version: git-master

 Thread 1:
 Variable: `s->dc_val[0][xy     + wrap]`
 Access: `s->dc_val[0][xy     + wrap] = 1024;`
 Line number: mpegvideo.c, 1916
 Call stack:
 1. `ff_clean_intra_table_entries`
 2. `ff_mpv_reconstruct_mb`
 3. `encode_thread`
 4. `worker_func`
 5. `run_jobs`
 6. `thread_worker`
 Lock:
 1. `w->mutex` (Call stack: `thread_worker`->`pthread_mutex_lock`)

 Thread 2:
 Variable: `dc_val[-wrap]`
 Access: `c = dc_val[-wrap];`
 Line number: mpeg4video.h, 224
 Call stack:
 1. `ff_mpeg4_pred_dc`
 2. `ff_mpeg4_encode_mb`
 3. `encode_thread`
 4. `worker_func`
 5. `run_jobs`
 6. `thread_worker`
 Lock:
 1. `w->mutex` (Call stack: `thread_worker`->`pthread_mutex_lock`)

 **Additional information**
 `s->dc_val[0][xy     + wrap]` in thread 1 and `dc_val[-wrap]` in thread 2
 are the same variable becasue their memory address are same. Althougth
 having the same name, the lock `w->mutex` in thread 1 is different from
 the one in thread

 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.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/8669>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker