By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,389 Members | 1,844 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,389 IT Pros & Developers. It's quick & easy.

How to identify who cause memory leak

P: n/a
Is there any debugging mechanism to find out which part of the code is
causing memory leak?

Dec 8 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a

NewToCPP wrote:
Is there any debugging mechanism to find out which part of the code is
causing memory leak?


http://freshmeat.net/search/?q=memor...&Go.x=0&Go.y=0

Dec 8 '05 #2

P: n/a
NewToCPP wrote:
Is there any debugging mechanism to find out which part of the code is
causing memory leak?


Not in the C++ language itself. There are many third party utilities
that do so, but they are dependent upon your platform.

I suggest that you ask in a newsgroup more relevant to your platform,
such as either one of the microsoft.public.* newsgroups or
comp.unix.programmer, or whatever the mac programming newsgroups are.

There will be developers there who have dealt with this sort of thing,
and can tell you better what's available.

*** ON THE OTHER HAND ***

Many memory leaks can be avoided by not using dynamic memory if at all
possible, or by using containers and smart pointers.

e.g. If you have a pointer that points to a single instance, use the
smart pointer of your choice. If you have a pointer to multiple
elements, which you're using as a dynamic array, then try std::vector
instead. You should also use std::vector instead of arrays. If you're
allocating char* to use as strings, then you should be using std::string
instead.

By using these elements instead of trying to manage memory yourself, you
will minimize your leakage, because these containers (string, vector)
and smart pointers will manage the memory for you, freeing it when it is
no longer needed.

You should also google for the term RAII (or Resource Acquisition Is
Initialization).
Dec 8 '05 #3

P: n/a
NewToCPP wrote:
Is there any debugging mechanism to find out which part of the code is
causing memory leak?


It is not a debugging mechanism, but:
If you work on Linux, use the "valgrind" tool. It's the best tool for
this I know about. It works non-invasive (you don't need to change any
code - it works on the executable), which is very nice.

Gabriel

--
Who is General Failure and why is he reading my hard disk?
Dec 9 '05 #4

P: n/a
NewToCPP wrote:
Is there any debugging mechanism to find out which part of the code is
causing memory leak?


You can use the leaktracker program which is a free program that has
the source code available. With the leaktracker program you can run
your program, and when your program exits, the leaktracker program will
automatically write to a file all memory leaks detected, which includes
line number, sourc file name, and even function name where the leak was
created.
The leaktracker program detects leaks created by new, new[], malloc,
realloc, and much more. It also detects resource leaks created by C
functions like fopen.
For windows platforms, it also has resource leak detection for windows
API functions that use HANDLE type.

Check out the following link:
http://code.axter.com/leaktracker.h
If you're target is windows, you can use the above link along with the
DLL and Lib file in the following zip file to track memory leaks:
http://code.axter.com/leaktracker.zip

The program is free, and if you need the source code you can get it via
following link:
http://code.axter.com/leaktracker_dll_source_code.zip

The code has been tested in Windows environment with MS VC++ 6.0, 7.1,
GNU 3.x, and Borland 5.5.

Although it's targeted for Windows, it wouldn't be that hard to port it
to other platforms, since the Windows related part of the code has
#ifdef WIN32 wrap.

For more information, read the entire commented section of the
leaktracker.h file.

I'm also open to any suggestions to make the program better, or more
portable.

Dec 9 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.