Unitialized read in CopyRow_AVX introduced between r1038 and r1130

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Sync WebRTC r7489
2. set GYP_DEFINES=build_for_tool=drmemory
   gclient runhooks
3. Compile libjingle_media_unittest in Debug mode
4. Run the test with: tools\valgrind-webrtc\webrtc_tests.bat --build_dir 
src/out/Debug --test common_audio_unittests --tool drmemory_full ""

What is the expected output? What do you see instead?
Test should pass. Instead it fails like this:
http://build.chromium.org/p/client.webrtc/builders/Win%20DrMemory%20Full/builds/
1205/steps/libjingle_media_unittest/logs/stdio

UNINITIALIZED READ: reading 0x04318ea0-0x04318ec0 32 byte(s) within 
0x04318ea0-0x04318ec0
#0 CopyRow_AVX                 
#1 CopyPlane                   
#2 I420Copy                    
#3 I420Rotate                  
#4 ConvertToI420               
#5 cricket::WebRtcVideoFrame::Reset
#6 cricket::WebRtcVideoFrame::Init
#7 WebRtcVideoFrameTest::TestInit
#8 WebRtcVideoFrameTest_InitEvenSize_Test::TestBody
#9 testing::internal::HandleSehExceptionsInMethodIfSupported<>
Note: @0:02:50.174 in thread 1620
Note: instruction: vmovdqu (%eax) -> %ymm0
Suppression (error hash=#5E132DBC3BD73684#):
  For more info on using suppressions see http://dev.chromium.org/developers/how-tos/using-drmemory#TOC-Suppressing-error-reports-from-the-
{
UNINITIALIZED READ
name=<insert_a_suppression_name_here>
*!CopyRow_AVX
*!CopyPlane
*!I420Copy
*!I420Rotate
*!ConvertToI420
*!cricket::WebRtcVideoFrame::Reset
*!cricket::WebRtcVideoFrame::Init
*!WebRtcVideoFrameTest::TestInit
*!WebRtcVideoFrameTest_InitEvenSize_Test::TestBody
*!testing::internal::HandleSehExceptionsInMethodIfSupported<>
}

What version of the product are you using? On what operating system?
It started failing when we rolled Chromium revision (and therefore also libyuv 
1038:1130 in https://code.google.com/p/webrtc/source/detail?r=7489

Please provide any additional information below.

Original issue reported on code.google.com by kjellan...@google.com on 22 Oct 2014 at 1:44

[GoogleCodeExporter]

I'm wondering whether this is DrMemory being overly aggressive, I'm not sure 
that vmovdqu should trigger an uninitialized read, it's just copying stuff, not 
acting on it. I've asked zhaoqin@ to take a look, but I can't +cc people here.

Original comment by pbos@google.com on 22 Oct 2014 at 2:00

[GoogleCodeExporter]

Unfortunately, Dr. Memory does not yet propagate shadow values for ymm 
registers (covered by https://code.google.com/p/drmemory/issues/detail?id=1485).

Original comment by bruen...@chromium.org on 22 Oct 2014 at 3:15

[GoogleCodeExporter]

The propagation tracking is not completely finished for multi-media 
instructions, so there are some instructions doing the uninit-check on first 
touching it instead of first significant use. Will look into that.

Original comment by zhao...@google.com on 22 Oct 2014 at 3:17

[GoogleCodeExporter]

This needs to be tested on a CPU with AVX2 I assume.
For purposes of Dr Memory, you can turn off AVX2 with compile flags or 
environment variables.
set LIBYUV_DISABLE_AVX2=1
set LIBYUV_DISABLE_AVX=1

Original comment by fbarch...@google.com on 22 Oct 2014 at 6:55

[GoogleCodeExporter]

As the bug appears to be in DrMemory not libyuv, putting this as 'New', not 
accepted.

Original comment by fbarch...@google.com on 22 Oct 2014 at 6:56

• Changed state: New

[GoogleCodeExporter]

As the issue is in Dr Memory, I'd like to close the libyuv bug

Original comment by fbarch...@google.com on 9 Feb 2015 at 7:46

• Changed state: Invalid

[GoogleCodeExporter]

FYI- the bug is real but not in YUV. The test case itself allocates memory but 
do not initalize it before calling libyuv.

Fixed by magjed in https://webrtc-codereview.appspot.com/41029004/.
I will remove the suppression.

Original comment by perkj@webrtc.org on 3 Mar 2015 at 9:33