Skip to content

Data Race in analyse.c and frame.c

Dear X264 developers:

I used my fuzz-testing tool, connzer, to detect data race in X264. Here is a data race found by connzer. I wish you can help me confirm the race, thanks!!

The following is the race report.

Race report

Thread 1

Race variable: h->fref[l][ ref >> MB_INTERLACED ]->orig->i_lines_completed

Access: completed = h->fref[l][ ref >> MB_INTERLACED ]->orig->i_lines_completed;

Line number: analyse.c; 3860

Call stack:

  1. analyse_update_cache
  2. mb_analyse_b_rd
  3. x264_8_macroblock_analyse
  4. slice_write
  5. slices_write
  6. threadpool_thread_internal
  7. threadpool_thread

Lock: None

Thread 2

Race variable: frame->i_lines_completed

Access: frame->i_lines_completed = i_lines_completed;

Line number: frame.c; 681

Call stack:

  1. x264_8_frame_cond_broadcast
  2. fdec_filter_row
  3. slice_write
  4. slices_write
  5. threadpool_thread_internal
  6. threadpool_thread

Lock: frame->mutex (Call stack: threadpool_thread->threadpool_thread_internal->slices_write->slice_write->fdec_filter_row->x264_8_frame_cond_broadcast->pthread_mutex_lock)

My fuzzer finds that these 2 accesses can be executed concurrently, and they are protected by different locks, so my fuzzer report this race.

Note

To prove the data race is real, I set breakpoints before these two accesses 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.

Edited by Zu-Ming Jiang
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information