0

Valgrind is complaining of bytes being possibly lost in one part of our large C++ program. After reading this SO question and the manual on "possibly lost" I think I understand what the error is about, but I don't understand the error in this specific case.

mpConsDbKey is not modified anywhere in the class (or derived classes), so the pointer is not being advanced or reassigned. The valgrind manual says "possibly lost" could also be declared if a "random value in memory points into the block"

Is there any way to know, via Valgrind, why it thinks it is lost?

If it is a random block of memory, best to not waste time looking for it...

Valgrind Manual

"Possibly lost". This covers cases 5--8 (for the BBB blocks) above. This means that a chain of one or more pointers to the block has been found, but at least one of the pointers is an interior-pointer. This could just be a random value in memory that happens to point into a block, and so you shouldn't consider this ok unless you know you have interior-pointers.

Source Code & Error

DvDaTestBC::DvDaTestBC()
{
    mpConsDbKey = new DvDbConsolidator; // <<== error here
}


DvDaTestBC::~DvDaTestBC()
{
    delete mpConsDbKey;
}

Type Hierarchy:

enter image description here

Error Text:

==2745== 88 bytes in 1 blocks are possibly lost in loss record 5,750 of 8,333
==2745==    at 0x4007D47: operator new(unsigned int) (vg_replace_malloc.c:292)
==2745==    by 0x50B5ED8: DvDaTestBC::DvDaTestBC(unsigned long, unsigned short, unsigned long, std::string const&, short) (DvDaTestBC.cpp:68)
==2745==    by 0x50BCCCE: DvDaTest::DvDaTest(unsigned long, unsigned short, unsigned long, std::string const&, DvDbAlarmConfigSet const&, Dv::ETestState, short) (DvDaTest.cpp:23)
==2745==    by 0x52157F1: DvDaMipErrorReporter::createTests() (DvDaMipErrorReporter.cpp:177)
==2745==    by 0x521427F: DvDaMipErrorReporter::DvDaMipErrorReporter(unsigned short, unsigned short) (DvDaMipErrorReporter.cpp:65)
==2745==    by 0x554DE25: DvCfgTspModuleMgrBC::createDAs() (DvCfgTspModuleMgrBC.cpp:742)
Danny
  • 2,221
  • 2
  • 24
  • 37
  • Probably `DvDaTestBC` is part of some inheritance hierarchy lacking [virtual destructors](https://stackoverflow.com/questions/461203). – Henri Menke Sep 03 '17 at 04:49
  • You should check whether the destructor is actually being called by printing a message to the terminal or so. – Henri Menke Sep 03 '17 at 04:51
  • That's a good hint. Question: do classes both above AND below `DvDaTestBC` need virtual destructors? Or just `DvDaTestBC` and above? (Not all classes in the hierarchy have virtual methods). See type hierarchy above – Danny Sep 03 '17 at 05:07
  • @Danny It depends how the `DvDaTestBC` object is being destroyed. If it's being deleted via a pointer to a base type, that base type (or an ancestor of that base type) needs a virtual destructor. Also, make sure `DvDaTestBC` obeys the rule of three/five. – cdhowie Sep 03 '17 at 05:12

0 Answers0