How to Spot Memory Leaks?

What's the easiest way to output how much memory my program is leaking? (Total allocations / deallocations) (Also, I'm just using new/delete, not malloc/free)

I am mainly using unix (gdb/g++) if that makes it easier. Or I can also copy my code files into MS Visual C++ on WinXP if there's a better way there?

Use valgrind if you're on Unix/Linux.

Quote:

---

Originally Posted by Salem

Use valgrind if you're on Unix/Linux.

---

Ahhh! Thanks!

Now I'm running my program like this: valgrind --leak-check=full ./proj < inp1

This gives me:

Code:

---

==31508== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 15 from 1)
==31508== malloc/free: in use at exit: 1,602 bytes in 108 blocks.
==31508== malloc/free: 232 allocs, 124 frees, 3,361 bytes allocated.
==31508== For counts of detected errors, rerun with: -v
==31508== searching for pointers to 108 not-freed blocks.
==31508== checked 121,928 bytes.
==31508==
==31508== 116 (64 direct, 52 indirect) bytes in 4 blocks are definitely lost in loss record 7 of 12
==31508==    at 0x4005BA5: operator new(unsigned) (vg_replace_malloc.c:163)
==31508==    by 0x804A5A4: SCLLRep::Insert(Element*) (SCLL.cpp:57)
==31508==    by 0x8048E51: main (proj.cpp:72)
==31508==
==31508==
==31508== 398 bytes in 27 blocks are possibly lost in loss record 12 of 12
==31508==    at 0x4005BA5: operator new(unsigned) (vg_replace_malloc.c:163)
==31508==    by 0x34071FA: std::string::_Rep::_S_create(unsigned, unsigned, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.8)
==31508==    by 0x3407D97: std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned) (in /usr/lib/libstdc++.so.6.0.8)
==31508==    by 0x3408947: std::string::reserve(unsigned) (in /usr/lib/libstdc++.so.6.0.8)
==31508==    by 0x33DF2E9: std::basic_istream<char, std::char_traits<char> >& std::operator>><char, std::char_traits<char>, std::allocator<char> >(std::basic_istream<char, std::char_traits<char> >&, std::basic_string<char, std::char_traits<char>, std::allocator<char> >&) (in /usr/lib/libstdc++.so.6.0.8)
==31508==    by 0x8048E96: main (proj.cpp:77)
==31508==
==31508== LEAK SUMMARY:
==31508==    definitely lost: 64 bytes in 4 blocks.
==31508==    indirectly lost: 52 bytes in 4 blocks.
==31508==      possibly lost: 398 bytes in 27 blocks.
==31508==    still reachable: 1,088 bytes in 73 blocks.
==31508==        suppressed: 0 bytes in 0 blocks.
==31508== Reachable blocks (those to which a pointer was found) are not shown.
==31508== To see them, rerun with: --show-reachable=yes

---

Is there a way to get more information about a certain leak?

For example, none of the bolded leaks above have file or line numbers. Can I get more detailed about these specific leaks?

The line numbers that matter are really the ones in YOUR code - what is on line 77 of your proj.cpp? I don't believe the C++ library is leaking on simple string operations, which means that it's likely that you do something like this:

Code:

---

std::string *s = new string(10);
...

---

and never do the corresponding:

Code:

---

delete s;

---

--
Mats

Best way is to use smart pointers to avoid leaks in the first place, though.
(See boost::shared_ptr or std::tr1::shared_ptr)

Quote:

---

Originally Posted by matsp

The line numbers that matter are really the ones in YOUR code - what is on line 77 of your proj.cpp? I don't believe the C++ library is leaking on simple string operations, which means that it's likely that you do something like this:

Code:

---

std::string *s = new string(10);
...

---

and never do the corresponding:

Code:

---

delete s;

---

--
Mats

---

That's the odd thing.

I have:

Code:

---

string oper, r, x;

---

And line 77 is:

Code:

---

cin >> r >> x;

---

The cin line appears elsewhere in main as well, and the fact that it doesn't yell at me on those for the same reason is the odd thing...

Noob question: ALL memory deallocation in C++ is just with the "delete" keyword, correct? Don't need to do anything else?

(From C, we learned about "free" in class but never used it in any assignments.)

It does make me think that it's a "false positive".

--
Mats

Quote:

---

Originally Posted by matsp

It does make me think that it's a "false positive".

--
Mats

---

Ah ok cool. I'll try to patch some holes up when I'm done coding the project and see if it goes away!

But yes, in C++, it's all just "delete", correct?

delete for single allocation and delete [] for block allocation.

ie...

Code:

---

int *x = new int;
delete x;

int *y = new int[100];
delete []y;

---

If you do not use the [] version where you should, you potentially leak memory.

You must make sure that you delete arrays with the array form of delete:

Code:

---

char *p = new char [10];
...

delete [] p;

---

--
Mats

Quote:

---

But yes, in C++, it's all just "delete", correct?

---

Not quite (e.g., as you pointed out the memory management functions from C are available in C++), but generally you would use delete to match new and delete[] to match new[].

Is SCLLRep your class? Does it have an Insert function that takes an Element*? I would look at that as the possible cause.

Quote:

---

Originally Posted by Paul22000

But yes, in C++, it's all just "delete", correct?

---

In summary:
Allocations with new[] is matched with delete[].
Allocations with new is matched with delete.
Allocations with malloc is matched with free.

New/delete is the C++ way, but the C way is also possible under C++.
Malloc should never be paired with delete.

Quote:

---

Originally Posted by Elysia

New/delete is the C++ way, but the C way is also possible under C++.
Malloc should never be paired with delete.

---

And to add to that, malloc() should not be used to ever allocate memory directly for an object of a type of class, since malloc() and free() do not handle the constructors and deconstructors of whatever type you are allocating. They just deal with raw memory.

So to reiterate, new/delete is the way to go in C++.

Since we're adding things, I'd add that in modern C++, the use of smart pointers often means that the delete is hidden (in many cases the new is hidden as well, but not all of them). So it is entirely possible to use new but not call delete directly because you use a smart pointer to handle that for you.

Quote:

---

Originally Posted by matsp

You must make sure that you delete arrays with the array form of delete:

Code:

---

char *p = new char [10];
...

delete [] p;

---

--
Mats

---

Thanks for the info on delete [] everyone!

I would have definitely flubbed that up haha

>> Thanks for the info on delete [] everyone!

Note that you should almost never be using delete[] in an actual C++ program, because there are few reasons to use a dynamically allocated array. If you think you need new[] and delete[], use vector instead.

Quote:

---

Originally Posted by Daved

Is SCLLRep your class? Does it have an Insert function that takes an Element*? I would look at that as the possible cause.

---

Yes it does.

Main creates a *pointer, and then inserts it into a list.

Is that copy by value? So delete the pointer after inserting?

Code:

---

string x;
cin >> x;
Element* pointerToElement = new Element(x);

Set* pointerToSet = ...
...
pointerToSet->Insert(pointerToElement);

// Delete pointerToElement?

---

It depends on what the Insert function does. Normally, you don't want to delete the pointer after calling insert, but if the set is storing objects and not pointers, then maybe you do.

Do you have the code or the documentation on what Insert is doing exactly?

If the Set owns the objects it holds (i.e. it is storing objects or allocating its own pointers), I wouldn't even be using new in the first place to create the Element, I'd create a local variable.