Re: debugging memory leaks
From: Bonj (benjtaylor)
Date: 12/12/04
- Next message: Bonj: "returning generic type"
- Previous message: Agoston Bejo: "Re: Compiler doesn't always find template ctor"
- In reply to: LhK-Soft: "Re: debugging memory leaks"
- Messages sorted by: [ date ] [ thread ]
Date: Sun, 12 Dec 2004 16:13:00 -0000
> ...
> #include <malloc.h>
>
> #ifdef _DEBUG
> LPVOID operator myNew[] (size_t blocksize, const char *file, int line)
> {
> LPVOID ret = malloc(blocksize);
> TRACE(_T("*** Allocated memory: 0x%x, in file: \"%s\" at line %d"),
> (ULONG)ret, file, line);
> return ret;
> }
That's fine...
> void operator myDelete[] (LPVOID block, const char* file, int line)
> {
> TRACE(_T("*** Freed memory: 0x%x, in file: \"%s\" at line %d"),
> (ULONG)block, file, line);
> free(block);
> }
>
Yes...
>
> #define new(block) myNew(block, __FILE__, __LINE__)
> #define delete(block) myDelete(block, __FILE_, __LINE__)
>
> // else, when in Released mode - using default 'new' and 'delete'
> operators
> #endif
>
> int main()
> {
> char* c = new char[255];
> delete c;
I hate to criticise asy ou are so well meaning, but surely isn't that the
most glaring memory leak bug ever? new[] should be matched with delete[],
you've matched new[] with delete. (without the [].)
That allocates an entire array, but only deletes the first element of it -
and I'm unlikely to find that out since I've overloaded it with a function
that tells me that I've deleted that block.
The distinction between delete and delete[] in C++ came about because delete
can be very much faster if it can know that it only has to free one
element - when something is allocated with new, delete knows how big it is
because you are deleting a pointer to a certain type, so if you do
wchar_t w = new wchar_t;
delete w; //which is a wchar_t, hence delete knows to delete 2 bytes
But if you new[] something, it has to store the number of elements
somewhere - either in a lookup table or somewhere within the memory
allocated, BSTR-style. Apparently both of these are acceptable methods in
commercial grade compilers, but it essentially means that delete[] has to
lookup this information, so to prevent the normal delete having to do the
lookup aswell, you put square brackets on to tell it to look upthe
information as to how many elements there are.
I hope you haven't got lots of code like that that you've now got to
modify...:-)
I actually tend to use something like
#define NULLSAFEDELETE(x) {if(x != NULL) {delete x; x = NULL;}}
#define NULLSAFEDELETE_ARR(x) {if(x != NULL) {delete[] x; x = NULL;}}
That way, I can call it on anything, and I don't have to worry about
accidentally calling it on a NULL pointer. It also had the unforeseen
advantage that I could modify all my calls to delete([]) in all one place...
but like Victor says I don't actually need to know in what functions
delete([]) was called, I just need to know what blocks were freed- I can
then deduce what (if any) blocks were new'ed and not deleted, but since I do
know where the new occurred, I can work out where the delete *should* have
occurred.
> Then view the 'Output'-pane of VisualStudio
If I used VisualStudio, I'd not have the pleasure of this challenge - I'd
just fall back on the use of _CrtDumpMemoryLeaks. Although even that doesn't
tell me about SysFreeString/SysAllocString bugs.
- Next message: Bonj: "returning generic type"
- Previous message: Agoston Bejo: "Re: Compiler doesn't always find template ctor"
- In reply to: LhK-Soft: "Re: debugging memory leaks"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
