Error in xEncodeInterResidual when called from xCheckRDCostInterIMV

[deluxan]

Valgrind detects uninitialised values being used in xEncodeInterResidual when called from xCheckRDCostInterIMV.

The command is

valgrind --tool=memcheck --leak-check=full --track-origins=yes ./EncoderAppStaticp -c encoder_randomaccess_vtm.cfg -c BasketballPass.cfg -f 17
--QP=37

And the first error detected by valgrind for POC 8 is the following:

==8262== Conditional jump or move depends on uninitialised value(s)
==8262== at 0x2C7599: EncCu::xEncodeInterResidual(CodingStructure*&, CodingStructure*&, Partitioner&, EncTestMode const&, int, bool*, double*) (EncCu.cpp:4262)
==8262== by 0x2CC85E: EncCu::xCheckRDCostInterIMV(CodingStructure*&, CodingStructure*&, Partitioner&, EncTestMode const&, double&) (EncCu.cpp:3989)
==8262== by 0x2D2692: EncCu::xCompressCU(CodingStructure*&, CodingStructure*&, Partitioner&, double) (EncCu.cpp:766)
==8262== by 0x2D611D: EncCu::compressCtu(CodingStructure&, UnitArea const&, unsigned int, int const*, int const*) (EncCu.cpp:366)
==8262== by 0x232B6B: EncSlice::encodeCtus(Picture*, bool, bool, unsigned int, unsigned int, EncLib*) (EncSlice.cpp:1760)
==8262== by 0x234601: EncSlice::compressSlice(Picture*, bool, bool) (EncSlice.cpp:1448)
==8262== by 0x20C5A9: EncGOP::compressGOP(int, int, std::cxx11::list<Picture*, std::allocator<Picture*> >&, std::cxx11::list<UnitBuf<short>*, std::allocator<UnitBuf<short>*> >&, bool, bool, InputColourSpaceConversion, bool, bool) (EncGOP.cpp:2272)
==8262== by 0x21B8FF: EncLib::encode(bool, PelStorage*, PelStorage*, InputColourSpaceConversion, std::cxx11::list<UnitBuf<short>*, std::allocator<UnitBuf<short>*> >&, int&) (EncLib.cpp:633)
==8262== by 0x11CDB7: EncApp::encode() (EncApp.cpp:749)
==8262== by 0x116646: main (encmain.cpp:153)
==8262== Uninitialised value was created by a stack allocation
==8262== at 0x2C7466: EncCu::xEncodeInterResidual(CodingStructure*&, CodingStructure*&, Partitioner&, EncTestMode const&, int, bool*, double*) (EncCu.cpp:4233)
==8262==

[XiangLi]

It looks the issue has been fixed with several related merge requests. Could you check whether the current master is OK? Thanks.

[deluxan]

It is actually corrected since master version "bbf94d32".