9

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

ks1322
  • 33,961
  • 14
  • 109
  • 164
user2470057
  • 529
  • 4
  • 17
  • 1
    Get rid of the `...` and post a full class that shows what you're observing. You're potentially hiding code behind those `...` that causes the allocation to occur. – PaulMcKenzie Aug 02 '15 at 18:22
  • Why do you say there are allocations happening? Because of valgrind? Also, well-written C++ code will not any any explicit calls to `new`, but will have lots of automatic allocations behind the scenes. Do not make the mistake of thinking that writing C++ is about calling `new` and `delete`. – Aaron McDaid Aug 02 '15 at 18:25
  • I didn't want to post code that wasn't important to the problem. I set up breaks in my code, and this is all that is running for me to get an alloc... and yes, valgrind said that it has happened. Is it a problem with valgrind? – user2470057 Aug 02 '15 at 18:27
  • 1
    @user2470057 `I didn't want to post code that wasn't important to the problem` Then post a *complete* example that shows the issue. Code that you may believe is not important may well be important. Or remove those ellipses, complete the class by giving it a trailing semicolon, stick it above `main()`, and remove the ellipses from `main`. – PaulMcKenzie Aug 02 '15 at 18:28
  • OK seriously, the rest of the code is unimportant. I just ran valgrind with this current code (... removed)... and I got this: ==11857== HEAP SUMMARY: ==11857== in use at exit: 72,704 bytes in 1 blocks ==11857== total heap usage: 1 allocs, 0 frees, 72,704 bytes allocated ==11857== still reachable: 72,704 bytes in 1 blocks – user2470057 Aug 02 '15 at 18:42
  • "Rerun with --leak-check=full to see details of leaked memory" -- have you tried to run Valgrind with this option? – myaut Aug 02 '15 at 19:30
  • Yes, --leak-check=full gives me the exact same output. I have tried to figure out this issue for 3 days now. I have researched everything I can think of and I can't make this go away. – user2470057 Aug 02 '15 at 19:35
  • It is actually impossible for this code to produce a memory leak. What compiler are you using? I just run the code in VS using _CrtDumpMemoryLeaks() and no leak was detected (obviously). C++ will never allocate any memory from the heap if you are not telling it to do – Chris Aug 02 '15 at 19:46
  • Since you are using C++ (as the tag shows), prefer to use `std::string` as data members rather than pointers to a single char. Pointers increase the programming difficulty (such as copy constructors and assignments). Not to mention dynamic memory handling. – Thomas Matthews Aug 02 '15 at 20:12
  • Like I said, I'm following a course outline. I would love to use std::string, but I'm required to use his headers and driver code... so either he knows about this, or he doesn't. Either way, I am sure he wants me to understand the issue and fix it. I'm currently using g++. I'll try another compiler and post the results. – user2470057 Aug 02 '15 at 20:16
  • While doing so, update your question info with the platform info this is done on. Your posted code, short of the slew of warnings, emits no reachable leaks on OSX 10.10.4 compiling with clang 3.6 and using Valgrind-3.11.0.SVN and LibVEX. There are a litany of *suppressions* from the runtime startup and shutdown, but nothing reachable from your code (obviously, since you perform *no dynamic allocation*. That info belongs in your question; not buried in a comment down here. – WhozCraig Aug 02 '15 at 20:19
  • [See this question](http://stackoverflow.com/questions/30513642/how-to-delete-new-pointer-that-declared-on-function-parameters/) – milleniumbug Aug 02 '15 at 22:28
  • @unordered_meow Thank you! You found the error. It is most definitely this issue! I'll update everything. – user2470057 Aug 03 '15 at 02:46
  • Please do not edit the solution into your question. Instead, accept a posted solution. You may post your own solution if nobody has posted a good one yet. – M.M Aug 03 '15 at 03:36

1 Answers1

14

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.

user2470057
  • 529
  • 4
  • 17