Valgrind Error: in use at exit: 72,704 bytes C++ I

Question

Issue:

I have a weird issue that I wasn't expecting. I have a class called Answers and within the header is this:

class Answer
{
    char* aText;
    bool b_correct;
public:
    Answer():aText(0){;}  //default constructor
}

The main (testing) driver code is this:

int main(void) 
{

    static const unsigned int MAX_ANSWERS = 5;
    Answer answers[MAX_ANSWERS];
}

The (unexpected) weirdness I am getting is that there is an alloc happening, and I haven't used a new anywhere in my code yet. I'm guessing that the char* is calling this in the initialization list.

I am using valgrind to test my code, and I'm getting 11 allocs and 10 frees. When I remove the initializer of :aText(0), the extra alloc goes away.

I get that this is badly constructed code. I am following a course outline to learn how to write in C++. Can someone please help me understand how the memory is allocated or what's happening during the initialization list to cause a call to new?

I know the error is coming from the code shown. I know the extra alloc is happening When I compile and run just this code.

Valgrind Output:

==12598== Memcheck, a memory error detector
==12598== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==12598== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==12598== Command: ./Answers
==12598== 
==12598== 
==12598== HEAP SUMMARY:
==12598==     in use at exit: 72,704 bytes in 1 blocks
==12598==   total heap usage: 1 allocs, 0 frees, 72,704 bytes allocated
==12598== 
==12598== LEAK SUMMARY:
==12598==    definitely lost: 0 bytes in 0 blocks
==12598==    indirectly lost: 0 bytes in 0 blocks
==12598==      possibly lost: 0 bytes in 0 blocks
==12598==    still reachable: 72,704 bytes in 1 blocks
==12598==         suppressed: 0 bytes in 0 blocks
==12598== Rerun with --leak-check=full to see details of leaked memory
==12598== 
==12598== For counts of detected and suppressed errors, rerun with: -v
==12598== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Platform Information:

Fedora 22

gcc.x86_64 5.1.1-4.fc22

valgrind.x86_64 1:3.10.1-13.fc22

codeblocks.x86_64 13.12-14.fc22

Answer 1

This is a known GCC 5.1 bug, not a valgrind bug.

Details here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64535

Possible workarounds: Downgrade GCC to an earlier version or wait for Valgrind to update a fix for this error. Both solutions are being worked on by their respective communities.