Valgrind warnings with random input

[GoogleCodeExporter]

What is the expected behavior? What do you see instead?

When giving the codec random input I'm expecting no valgrind warnings, but I'm 
able to reproduce at least one warning:
==7344== Conditional jump or move depends on uninitialised value(s)
==7344==    at 0x4104F0: vp8_intra4x4_predict_c (in 
/usr/local/google/users/holmer/code/libvpx/build/simple_decoder)
==7344==    by 0x43013C: vp8_decode_frame (in 
/usr/local/google/users/holmer/code/libvpx/build/simple_decoder)
==7344==    by 0x40316B: vp8dx_receive_compressed_data (in 
/usr/local/google/users/holmer/code/libvpx/build/simple_decoder)
==7344==    by 0x40219E: ??? (in 
/usr/local/google/users/holmer/code/libvpx/build/simple_decoder)
==7344==    by 0x401711: vpx_codec_decode (in 
/usr/local/google/users/holmer/code/libvpx/build/simple_decoder)
==7344==    by 0x40141A: main (in 
/usr/local/google/users/holmer/code/libvpx/build/simple_decoder)

What version are you using? On what operating system?

commit 7177c3220c

Can you reproduce using the vpxdec or vpxenc tools? What command line are
you using?

I can reproduce by modifying simple_decoder with the attached patch.

Please provide any additional information below.

The issue was initially found by the webrtc fuzz test. See these links for 
additional errors found:
https://code.google.com/p/webrtc/issues/detail?id=618
https://code.google.com/p/webrtc/issues/detail?id=761
https://code.google.com/p/webrtc/issues/detail?id=787

It's not clear that all of these issues are caused by libvpx, but since I was 
able to trigger at least one issue by including only libvpx code it seems 
reasonable that there are more to be found.

Original issue reported on code.google.com by stefan@webrtc.org on 29 Aug 2012 at 2:46

Attachments:

• patch.txt

[GoogleCodeExporter]

Jim will triage this bug 

Original comment by albe...@google.com on 30 Aug 2012 at 10:12

• Changed state: Assigned
• Added labels: Mstone-11

[GoogleCodeExporter]

The following 3 cls fix the random decoder valgrind issues. 

https://gerrit.chromium.org/gerrit/#/c/32855/,  
https://gerrit.chromium.org/gerrit/#/c/33006/, 
https://gerrit.chromium.org/gerrit/#/c/32627/

we've been unable to duplicate the encoder issues and wez@ suggested 

Original comment by jimbankoski@google.com on 12 Sep 2012 at 9:06

[GoogleCodeExporter]

Thanks for looking into this.

I think parts of your message above was lost. Anyway, I didn't mean to ask you 
to look into the encoder issues as I believe those are caused by alignment and 
odd width/height problems in WebRTC and will likely be solved by our 
refactoring of the webrtc::VideoFrame class.

I will roll this into WebRTC to see that the warnings are gone.

Original comment by stefan@webrtc.org on 13 Sep 2012 at 7:19

[GoogleCodeExporter]

We still seem to trigger a memory leak in setup_token_decoder(). This is also 
in our fuzz tests. See below for a callstack:

13:45:38 memcheck_analyze.py [ERROR] FAIL! There were 1 errors: 
13:45:38 memcheck_analyze.py [ERROR] Command:   
Leak_DefinitelyLost
136 bytes in 1 blocks are definitely lost in loss record 92 of 93
  malloc (m_replacemalloc/vg_replace_malloc.c:263)
  vpx_memalign (/usr/local/google/buildbot/webrtc-cb/cb/build/slave/linux-large-tests_stable/build-stable/trunk/out/Debug/vie_auto_test)
  vpx_malloc (/usr/local/google/buildbot/webrtc-cb/cb/build/slave/linux-large-tests_stable/build-stable/trunk/out/Debug/vie_auto_test)
  setup_token_decoder (/usr/local/google/buildbot/webrtc-cb/cb/build/slave/linux-large-tests_stable/build-stable/trunk/out/Debug/vie_auto_test)
  vp8_decode_frame (/usr/local/google/buildbot/webrtc-cb/cb/build/slave/linux-large-tests_stable/build-stable/trunk/out/Debug/vie_auto_test)
  vp8dx_receive_compressed_data (/usr/local/google/buildbot/webrtc-cb/cb/build/slave/linux-large-tests_stable/build-stable/trunk/out/Debug/vie_auto_test)
  vp8_decode (/usr/local/google/buildbot/webrtc-cb/cb/build/slave/linux-large-tests_stable/build-stable/trunk/out/Debug/vie_auto_test)
  vpx_codec_decode (/usr/local/google/buildbot/webrtc-cb/cb/build/slave/linux-large-tests_stable/build-stable/trunk/out/Debug/vie_auto_test)
  webrtc::VP8Decoder::Decode(webrtc::EncodedImage const&, bool, webrtc::RTPFragmentationHeader const*, webrtc::CodecSpecificInfo const*, long) (/usr/local/google/buildbot/webrtc-cb/cb/build/slave/linux-large-tests_stable/build-stable/trunk/out/Debug/vie_auto_test)
  webrtc::VCMGenericDecoder::Decode(webrtc::VCMEncodedFrame const&, long) (/usr/local/google/buildbot/webrtc-cb/cb/build/slave/linux-large-tests_stable/build-stable/trunk/out/Debug/vie_auto_test)
  webrtc::VideoCodingModuleImpl::Decode(webrtc::VCMEncodedFrame const&) (/usr/local/google/buildbot/webrtc-cb/cb/build/slave/linux-large-tests_stable/build-stable/trunk/out/Debug/vie_auto_test)
  webrtc::VideoCodingModuleImpl::Decode(unsigned short) (/usr/local/google/buildbot/webrtc-cb/cb/build/slave/linux-large-tests_stable/build-stable/trunk/out/Debug/vie_auto_test)
  webrtc::ViEChannel::ChannelDecodeProcess() (/usr/local/google/buildbot/webrtc-cb/cb/build/slave/linux-large-tests_stable/build-stable/trunk/out/Debug/vie_auto_test)
  webrtc::ViEChannel::ChannelDecodeThreadFunction(void*) (/usr/local/google/buildbot/webrtc-cb/cb/build/slave/linux-large-tests_stable/build-stable/trunk/out/Debug/vie_auto_test)
  webrtc::ThreadPosix::Run() (/usr/local/google/buildbot/webrtc-cb/cb/build/slave/linux-large-tests_stable/build-stable/trunk/out/Debug/vie_auto_test)
  StartThread (/usr/local/google/buildbot/webrtc-cb/cb/build/slave/linux-large-tests_stable/build-stable/trunk/out/Debug/vie_auto_test)
Suppression (error hash=#48C51FF578470322#):
  For more info on using suppressions see http://dev.chromium.org/developers/tree-sheriffs/sheriff-details-chromium/memory-sheriff#TOC-Suppressing-memory-reports
{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   fun:malloc
   fun:vpx_memalign
   fun:vpx_malloc
   fun:setup_token_decoder
   fun:vp8_decode_frame
   fun:vp8dx_receive_compressed_data
   fun:vp8_decode
   fun:vpx_codec_decode
   fun:_ZN6webrtc10VP8Decoder6DecodeERKNS_12EncodedImageEbPKNS_22RTPFragmentationHeaderEPKNS_17CodecSpecificInfoEl
   fun:_ZN6webrtc17VCMGenericDecoder6DecodeERKNS_15VCMEncodedFrameEl
   fun:_ZN6webrtc21VideoCodingModuleImpl6DecodeERKNS_15VCMEncodedFrameE
   fun:_ZN6webrtc21VideoCodingModuleImpl6DecodeEt
   fun:_ZN6webrtc10ViEChannel20ChannelDecodeProcessEv
   fun:_ZN6webrtc10ViEChannel27ChannelDecodeThreadFunctionEPv
   fun:_ZN6webrtc11ThreadPosix3RunEv
   fun:StartThread
}

Original comment by stefan@webrtc.org on 13 Sep 2012 at 11:19

[GoogleCodeExporter]

OK I'll take another look but I thought that one was fixed by completely
removing the malloc in setup token decoder???

Original comment by jimbankoski@google.com on 13 Sep 2012 at 12:45

[GoogleCodeExporter]

Agree, that seems a bit strange. I will force a new fuzz run and see if it's 
still there.

Original comment by stefan@webrtc.org on 13 Sep 2012 at 12:55

[GoogleCodeExporter]

Sorry about that. I was looking at the wrong buildbot. The one I looked at was 
building the stable branch. The trunk buildbot is all green. Nice work!

Original comment by stefan@webrtc.org on 13 Sep 2012 at 12:57

[GoogleCodeExporter]

Cool!

Original comment by jimbankoski@google.com on 13 Sep 2012 at 1:34

[GoogleCodeExporter]

Original comment by louquil...@google.com on 13 Aug 2013 at 10:59

• Changed state: Fixed