Memory leak detector

[post from old forum]

Hi there,

As many programmers i like crawling the web and i found this link :
http://homepage.ntlworld.com/robertwalker/memleakcheck/

And an idea came to me...
As many of us are lazy developpers, i thought the public sources of this tool could be part of a PellesC extention that could check our code after compilation time to avoid us bad surprises ;-P

Just an idea, but can be a useful one ;-P

See ya,
Gerome

[post from old forum]

Hello,

Thank you for this useful link!  

Sounds like a good idea. Can't promise I will add it to the next release, but soon, I hope.

Pelle

[post from old forum]

Hi group,

if you would like to get rid of memory management chores once and for all, check out http://www.hpl.hp.com/personal/Hans_Boehm/gc/.

The BDW garbage collector is compact, stable and fast. I regard it very highly.

Hans

[post from old forum]

Thanks Hans,

I've already used the GC and it works fine
But his was not exactly the debate
It was a simple tool which usage will to show the programmer he has to revisit his code in order to avoid coding with his shoes

Yours,
Gerome GUILLEMIN
http://gedd123.free.fr/Documentation.htm

[post from old forum]

Bonjour Gerome,

well, the reason I suggested to use the BWD garbage collector was not just for convenience. It also has a mode that detects memory leaks. In this mode, you'd still 'free' every '(m|c)alloc' and use the collector to detect any leaks.

For shipment, you'd leave the gc out.

salut

Hans

[post from old forum]

Hi group,

for those of you that haven't yet used the BDW garbage collector, I'd like to show the following code snippet I use in all my sources:

//--- conditional inclusion of Boehmer-Demers garbage collector ---
#define GC_required YES
#ifdef GC_required
#include <gc.h>
#else
#include <malloc.h>
#include <memory.h>
#endif
#ifdef __GC
#define malloc(x) GC_malloc(x)
#define realloc(x) GC_realloc(x)
#define free(x) ((x)=NULL)
#define force_GC_on(x) GC_free(x)
#else
#define force_GC_on(x) free(x)
#endif
//------------------------------------------------------------------

This is all it takes to include the GC. From then on, you'd use malloc/realloc and free like you'd do without the GC. If you decide to include the BDW GC, you'll have to add GC.DLL to your distribution set.

Hope this helps to proliferate the use of the BDW GC!

Hans

[post from old forum]

Hi Hans,

If i follow your sample code, tested under LCC Win32 & PellesC, the GC_malloc works, the GC_realloc was buggy ( bad macro given ), and the following code demonstrate the GC_free does absolutely nothing : no free bytes are done

Yours,
Gerome

#include <windows.h>
//--- conditional inclusion of Boehmer-Demers garbage collector ---
#define GC_required YES
#ifdef GC_required
#include <gc.h>
#pragma lib <gc.lib>
#else
#include <malloc.h>
#include <memory.h>
#endif
#ifdef __GC
#define malloc(x) GC_malloc(x)
#define realloc(x,y) GC_realloc((x),(y))
#define free(x) ((x)=NULL)
#define force_GC_on(x) GC_free(x)
#else
#define force_GC_on(x) free(x)
#endif
//------------------------------------------------------------------

int main( void )
{
char *p = NULL;

// Allocates 16 MB
p = malloc( 1024 * 1024 * 16 );
// Never free !
free(p);

// Allocates more than 48 MB !!!
p = GC_malloc( 1024 * 1024 * 32 );
// Never free !!
free(p);

return 0;
}

[post from old forum]

Bonjour Gerome,

through the included macro definition, your first 'free(p)' merely makes 'p' a null pointer. The memory location that 'p' pointed to is not necessarily reclaimed immediately. The garbage collector will free it at its own discretion, unless you force an immediate manual garbage collection by calling 'GC_free(p)'. For most applications, this is overkill. Remember, the point of using a GC is to free yourself from memory management (pun intended  )

Your first allocation should and does allocate 16 MB. Your second allocation should allocate 32 MB. This adds up to 48 MB. Most likely, when you allocate the second chunk of 32 MB, the GC has not yet reclaimed the 16 MB that was allocated first, hence your app uses up to 48 MB, plus a little bit of GC overhead.

To show that the GC is not at fault here, please include a timer loop at the end, or whatever that keeps the app alive for some more time. If you have tools to look at memory allocations while the app remains alive, you'll notice that eventually both memory block allocations will be reclaimed by the GC.

If you use free(p) when using my macro definitions, you're not actually freeing up anything at that moment. You're just telling the GC that it's save to reclaim the objects that your pointers pointed to. Unless you force the GC to do its thing immediate, the GC decides when it actually performs a garbage collection.

Hope this helps.

Hans

[post from old forum]

Gerome,

one thing I forgot: as to your remarks about the GC_realloc macro, I have to check that out. Grepping my source trees I found out that I apparently haven't used GC_realloc just yet. It looks like all I use are the malloc() and free() redefinitions...

Hans

[post from old forum]

Hi Hans,

The trick that bothers me is that following :
i have made a simple script language called FBSL that is able to cope with integers, string, float and pointers variable and a bunch of internal functions that allocates/unallocates memory.
To be ok with a treatment, i need to free the very pointer of an allocated variable, then nullifying it to continue my routine.
I have tested the GC with LCC but the GC_free frees nothing, especially when i need this very pointer to be freed, so i can't use it as i want, i can understad GC is cool, but too greedy when i need to shrink memory to its origin like i want, but i can't with GC...

Do you have any proposal ?
Yours,
Gerome GUILLEMIN
http://www.fbsl.net

[post from old forum]

Gerome,

the GC documentation explicitly states that GC_FREE(void *) is typically not useful for small collectable objects. The library offers another function to explicitly enfore a garbage collection. It's called GC_gcollect(void). More information can be found at http://www.hpl.hp.com/personal/Hans_Boehm/gc/gcinterface.html.

If that doesn't help, could you please publish a small snippet of code that illustrates what you're trying to achieve? I could check it out and see if I can help you out.

As a direct answer to your request for a proposal: theoretically, when using the BDW GC, you could simply allocate a new memory block with the existing pointer, without first freeing the memory block that the pointer points to at that moment. In normal C programming, this would indeed create a memory leak, but since you're using a GC, which you delegate all memory allocation to, there shouldn't be a need for freeing up anything at all. The GC should do that for you automatically. It keeps track of all memory it allocated, every memory block still in use and all memory blocks that can safely be reclaimed.

Hans