not important at all - memory leak

[Grahamo]

Hey,

this is related to absolutely nothing in particular and is of no
importance whatsoever except for my curiousity.

Does anybody have an example of a particularly tricky memory leak
that's hard to spot. I'd like to see something that's a little unusual
or obscure. something that involves some in depth knowledge about
functionality X or scenario X and that causes a memory leak. Something
that would be really easy to miss.

This is simply for curiousity sake and nothing more. if anybody has a
little code snippit or example I'd love to see it

cheers

G

[Axter]

Gr*****@nospam. com wrote:

Hey,

this is related to absolutely nothing in particular and is of no
importance whatsoever except for my curiousity.

Does anybody have an example of a particularly tricky memory leak
that's hard to spot. I'd like to see something that's a little unusual
or obscure. something that involves some in depth knowledge about
functionality X or scenario X and that causes a memory leak. Something
that would be really easy to miss.

This is simply for curiousity sake and nothing more. if anybody has a
little code snippit or example I'd love to see it

cheers

G

Mixing allocators with wrong deallocators can be easy to miss. (new[]
with delete), (new with delete[]), (new with free), etc....

Example:
int *i = new int(123); //This does NOT create an array
delete[] i; //Wrong deallocator

[Grahamo]

thanks, nice start. I would have spotted that one. I'm after one I
would NOT have spotted.... a really tricky one. Thanks though, I'm
compiling a list.

(non) virtual destructors in base classes is a good one, I already have
that.

any others...not run of the mill stuff.
cheers

Graham

[Jonathan Mcdougall]

Gr*****@nospam. com wrote:

Hey,

this is related to absolutely nothing in particular and is of no
importance whatsoever except for my curiousity.

Does anybody have an example of a particularly tricky memory leak
that's hard to spot. I'd like to see something that's a little unusual
or obscure. something that involves some in depth knowledge about
functionality X or scenario X and that causes a memory leak. Something
that would be really easy to miss.

This is simply for curiousity sake and nothing more. if anybody has a
little code snippit or example I'd love to see it

Well, ADL can change the meaning of a function call silently:

namespace N
{
class C{};

void f(C c, int i)
{
// deletes things
}
}

int main()
{
N::C c;
f(c, 1.0); // may give a conversion warning
}

Adding the global function

void f(C c, double d);

changes the meaning of the call to f(). If N::f() was in charge of
deleting things, you may be suprised.
Jonathan

[John Harrison]

Gr*****@nospam. com wrote:

Hey,

this is related to absolutely nothing in particular and is of no
importance whatsoever except for my curiousity.

Does anybody have an example of a particularly tricky memory leak
that's hard to spot. I'd like to see something that's a little unusual
or obscure. something that involves some in depth knowledge about
functionality X or scenario X and that causes a memory leak. Something
that would be really easy to miss.

This is simply for curiousity sake and nothing more. if anybody has a
little code snippit or example I'd love to see it

cheers

G

How about this

class Dodgy
{
Dodgy() : ptr(new char[99]) {}
~Dodgy() { delete[] ptr; }
char* ptr;
X x;
};

If the X constructor throws an exception then the memory allocated will
never get freed, even through the destructor does free the memory. This
is because in this case the destructor for Dodgy is never called.

john

[John Harrison]

Gr*****@nospam. com wrote:

thanks, nice start. I would have spotted that one. I'm after one I
would NOT have spotted.... a really tricky one. Thanks though, I'm
compiling a list.

(non) virtual destructors in base classes is a good one, I already have
that.

any others...not run of the mill stuff.
cheers

Graham

Niether of your two exmaples are memory leaks, they are undefined
behaviour. A memory leak is one possibility but not the only one (or
even the most likely one).

john

[Grahamo]

thanks for that... undefined behaviour is ok too. Good point though...
I've noted that point.

cheers
G

[John Harrison]

John Harrison wrote:

Gr*****@nospam. com wrote:

Hey,

this is related to absolutely nothing in particular and is of no
importance whatsoever except for my curiousity.

Does anybody have an example of a particularly tricky memory leak
that's hard to spot. I'd like to see something that's a little unusual
or obscure. something that involves some in depth knowledge about
functionality X or scenario X and that causes a memory leak. Something
that would be really easy to miss.

This is simply for curiousity sake and nothing more. if anybody has a
little code snippit or example I'd love to see it

cheers

G

How about this

class Dodgy
{
Dodgy() : ptr(new char[99]) {}
~Dodgy() { delete[] ptr; }
char* ptr;
X x;
};

If the X constructor throws an exception then the memory allocated will
never get freed, even through the destructor does free the memory. This
is because in this case the destructor for Dodgy is never called.

john

But this version is OK

class NotDodgy
{
NotDodgy() : ptr(new char[99]) {}
~NotDodgy() { delete[] ptr; }
X x;
char* ptr;
};

No memory leaks there.

john

[Grahamo]

?

[John Harrison]

Gr*****@nospam. com wrote:

?

The difference is the order of construction. If the X constructor is
called after the allocation of memory and the X constructor throws then
you have a memory leak. But in the second example the X constructor is
called before the memory allocation (because of the different order of
declarations) therefore when the X constructor throws the memory
allocation hasn't happened yet.

john