17 replies to this topic

[c___newbie]

Hi all,
I’m studying a problem releated to memory leakage.
Now, there are many tools to check memory leakake at run-time (dynamic analysis), and some tools can check memory leakage at compile-time (static analysis). But I have some questions:
How do you think to prevent memory leakage from coding phase (without using tool)? (or In coding phase, what do you have to do to prevent memory leakage?)
I want to investigate from many programmers in many countries.
Can you help me?

[WingedPanther]

The basic technique is to make sure that for every malloc() there is a corresponding free(). This takes care of the most obvious problem, but is far from error proof. For example, if you have code like the following:

int * ptr;
for (i=1;i<10;i++){ptr=malloc(int);}
free(ptr);

will leak memory like crazy because the malloc is inside the loop, but the free is outside the loop.
This type of situation can happen easily when dealing with data structures such as linked lists, where you'll have a pointer to the head of the list and the current node of the list, and each node has a pointer to the next node. When "deleting" the linked list you have to be very careful to free each node without losing access to the list in the process.

[G_Morgan]

I get lazy and use garbage collection. Let someone else worry about memory management :).

As I see it. Unless I need programs that are always instantly responsive (i.e. 10ms pauses are unacceptable) then there is little or no reason not to use conservative GC. It does not produce an overly undue overhead in terms of processor time (because the majority of the deallocation code is only called once per thousands of deallocations while with manual memory management it's called once per deallocation). The only real issue is that GC can cause intense spots of activity where the program locks up. This is not usually noticeable in most applications.

A lot of C++ programmers use smart pointers to implement reference counting GC. This can work at a near manual level of efficiency. The only issue is circular references but it does generally stabilise memory usage. For me that is the key, I want to be able to tell people that this application uses N MiB of memory. I don't care that it wastes O MiB as long as it wastes O statically and no more than O.

[Reji]

Can you, please, tell me some tools to check memory leakake at run-time?

[WingedPanther]

There are a variety of tools, depending on your OS, compiler, etc. The best tool will depend on the details of your environment.

[Reji]

OS-WinXP
environment- Microsoft Visual Studio 6.0
I was advised to use Deleaker. Is it really good?

[Sysop_fb]

Maintain control of your memory region pointers.
Never use your pointer for the return value of realloc because realloc isn't required to succeed, it can fail and return NULL and you can lose track of your original block of allocated memory so.. use a temporary pointer.

[WingedPanther]

VS6 isn't very good. I haven't used Deleaker.

[Reji]

Thanks

[roboticforest]

One thing you can look into (and I mean carefully research before trying) is overloading the global new and delete operators.

Doing this will allow you (if nothing else) to keep a running total of all allocations, and deallocations made during your program's run time. If you have more allocations than deallocations, then you have a leak somewhere.

This setup can get far more advanced, but there's a start.

[WingedPanther]

Using Boost::smart_ptr will do a lot to avoid memory leaks.

[dargueta]

On *nix systems, valgrind is a pretty good memory leak checker.

EDIT: It's definitely used in Linux, I think (but I'm not sure) that there's a Unix version as well.