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:
ff_clean_intra_table_entries
ff_mpv_reconstruct_mb
encode_thread
worker_func
run_jobs
thread_worker
Lock:
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:
ff_mpeg4_pred_dc
ff_mpeg4_encode_mb
encode_thread
worker_func
run_jobs
thread_worker
Lock:
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)
Change History (6)
by , 4 years ago
comment:1 by , 4 years ago
Dear developers:
I think it is a real race because I have reproduced it. Please help me confirm it, thanks.
comment:3 by , 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 , 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 , 4 years ago
Resolution: | → needs_more_info |
---|---|
Status: | new → closed |
The input file