Data races on cpi->mt_current_mb_col in vp8/encoder/ethreading.c

[GoogleCodeExporter]

TSAN is reporting data races in thread_encoding_proc() in ethreading.c:

WARNING: ThreadSanitizer: data race (pid=20045)
  Read of size 4 at 0x7d4400005794 by thread T18:
    #0 thread_encoding_proc chromium/src/third_party/libvpx/source/libvpx/vp8/encoder/ethreading.c:120 (webrtc_perf_tests+0x00000088d0fe)

  Previous write of size 4 at 0x7d4400005794 by thread T17:
    #0 thread_encoding_proc chromium/src/third_party/libvpx/source/libvpx/vp8/encoder/ethreading.c:116 (webrtc_perf_tests+0x00000088d0c5)

  Location is heap block of size 303 at 0x7d4400005780 allocated by main thread:
    #0 malloc <null> (webrtc_perf_tests+0x00000043cded)
    #1 vpx_memalign chromium/src/third_party/libvpx/source/libvpx/vpx_mem/vpx_mem.c:25 (webrtc_perf_tests+0x000000810e0e)
    ...

These lines correspond to  
  *current_mb_col = mb_col - 1;
and
  while (mb_col > (*last_row_current_mb_col - nsync))

Both of these are volatile pointers into the cpi->mt_current_mb_col struct:
  volatile const int *last_row_current_mb_col;
  volatile int *current_mb_col = &cpi->mt_current_mb_col[mb_row];

Just declaring them as volatile is not enough to make this thread safe; you 
need proper atomics.

This seems slightly related to issue 856.

Original issue reported on code.google.com by spr...@google.com on 22 Jul 2015 at 11:04

• Blocked on: #851, #856

[GoogleCodeExporter]

Don't forget issue 851.

Original comment by jz...@google.com on 22 Jul 2015 at 6:17

• Now blocked on: #851, #856

[GoogleCodeExporter]

Original comment by pbos@google.com on 22 Jul 2015 at 10:52

[GoogleCodeExporter]

Original comment by ya...@google.com on 30 Jul 2015 at 10:25

• Changed state: Available