Opened 4 years ago

Closed 4 years ago

#8667 closed defect (needs_more_info)

Data race in mpeg4video.h

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

Description

Note: To prove the data race is real, I set breakpoints before these two access when when they are running in the call stack described above. I find that the breakpoints can be activated simultaneously, and the address 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: `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)

Thread 2:
Variable: dc_val[0]
Access: dc_val[0] = level;
Line number: mpeg4video.h; 274
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
dc_val[-wrap] in thread 1 and dc_val[0] 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.

Change History (1)

comment:1 by Zu-Ming, 4 years ago

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