[x265] [PATCH] TComPicYuv: initialize picBuf to avoid valgrind's uninitialized pixel access report

[Steve Borho]

On Tue, Jun 24, 2014 at 8:07 AM,  <kavitha at multicorewareinc.com> wrote:
> # HG changeset patch
> # User Kavitha Sampath <kavitha at multicorewareinc.com>
> # Date 1403614220 -19800
> #      Tue Jun 24 18:20:20 2014 +0530
> # Node ID 65f3b95b70ced156433882d3d5fbc39160dfccaa
> # Parent  18f936182df50cc5126d1707cd7c2b5fef289ccb
> TComPicYuv: initialize picBuf to avoid valgrind's uninitialized pixel access report

This is a bit troubling.  It would seem to indicate that some encoder
process is reading past our extended borders.

This change would make valgrind shut up about the issue, since the
memory would no longer be uninitialized, but this doesn't fix the bug
in our logic that leads to the out-of-bounds read.

Perhaps another tool like Purify can catch the case where the
uninitialized memory is first read, rather than when it first
influences a logic decision as valgrind works.

> diff -r 18f936182df5 -r 65f3b95b70ce source/Lib/TLibCommon/TComPicYuv.cpp
> --- a/source/Lib/TLibCommon/TComPicYuv.cpp      Mon Jun 23 17:03:49 2014 -0700
> +++ b/source/Lib/TLibCommon/TComPicYuv.cpp      Tue Jun 24 18:20:20 2014 +0530
> @@ -92,6 +92,10 @@
>      CHECKED_MALLOC(m_picBuf[1], pixel, m_strideC * ((maxHeight >> m_vChromaShift) + (m_chromaMarginY * 2)));
>      CHECKED_MALLOC(m_picBuf[2], pixel, m_strideC * ((maxHeight >> m_vChromaShift) + (m_chromaMarginY * 2)));
>
> +    memset(m_picBuf[0], 0, m_stride * (maxHeight + (m_lumaMarginY * 2)));
> +    memset(m_picBuf[1], 0, m_strideC * ((maxHeight >> m_vChromaShift) + (m_chromaMarginY * 2)));
> +    memset(m_picBuf[2], 0, m_strideC * ((maxHeight >> m_vChromaShift) + (m_chromaMarginY * 2)));
> +
>      m_picOrg[0] = m_picBuf[0] + m_lumaMarginY   * getStride()  + m_lumaMarginX;
>      m_picOrg[1] = m_picBuf[1] + m_chromaMarginY * getCStride() + m_chromaMarginX;
>      m_picOrg[2] = m_picBuf[2] + m_chromaMarginY * getCStride() + m_chromaMarginX;
> _______________________________________________
> x265-devel mailing list
> x265-devel at videolan.org
> https://mailman.videolan.org/listinfo/x265-devel



-- 
Steve Borho