Opened 4 years ago

Closed 4 years ago

#8669 closed defect (needs_more_info)

Data race in mpegvideo.c and 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 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.

Attachments (1)

small.mp4 (374.6 KB ) - added by Zu-Ming 4 years ago.
The input file

Download all attachments as: .zip

Change History (6)

by Zu-Ming, 4 years ago

Attachment: small.mp4 added

The input file

comment:1 by Zu-Ming, 4 years ago

Dear developers:

I think it is a real race because I have reproduced it. Please help me confirm it, thanks.

comment:2 by Carl Eugen Hoyos, 4 years ago

How did you reproduce the issue an how can we reproduce it?

in reply to:  2 comment:3 by Zu-Ming, 4 years ago

Replying to cehoyos:

How did you reproduce the issue an how can we reproduce it?

I reproduce it using breakpoint. Specifically, I used llvm to instrument the code, and set breakpoint before the race instruction pair. By controling the breakpoints, I made the race instructions be executing concurrently. And then, I checked their access addresses and found they are same. So I am sure it is a real race .

It may be hard for you to reproduce it easily. Gdb may be a good choice but it may require some your manual effort to set the breakpoint.

comment:4 by Carl Eugen Hoyos, 4 years ago

Where do we have to set breakpoints to reproduce this issue?

I believe it is important to define that a valid ticket is one that can - at least theoretically - reproduced by a developer while a ticket where one person claims an issue without explaining how it can be reproduced is - by definition - not a valid ticket.

comment:5 by Carl Eugen Hoyos, 4 years ago

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