Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
743 views
in Technique[技术] by (71.8m points)

gcc - Valgrind Error: in use at exit: 72,704 bytes C++ Initialization List weirdness with char*

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

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Reply

0 votes
by (71.8m points)

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.


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
OGeek|极客中国-欢迎来到极客的世界,一个免费开放的程序员编程交流平台!开放,进步,分享!让技术改变生活,让极客改变未来! Welcome to OGeek Q&A Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

1.4m articles

1.4m replys

5 comments

56.8k users

...