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

not important at all - memory leak

P: n/a
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

Nov 22 '05 #1
Share this Question
Share on Google+
12 Replies


P: n/a
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

Nov 22 '05 #2

P: n/a
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

Nov 22 '05 #3

P: n/a
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

Nov 22 '05 #4

P: n/a
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
Nov 22 '05 #5

P: n/a
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
Nov 22 '05 #6

P: n/a
thanks for that... undefined behaviour is ok too. Good point though...
I've noted that point.

cheers
G

Nov 22 '05 #7

P: n/a
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
Nov 22 '05 #8

P: n/a
?

Nov 22 '05 #9

P: n/a
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
Nov 22 '05 #10

P: n/a

John Harrison wrote:
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.


I would note that this example is for illustrative purposes only, no
actual program would rely on something as fragile as the order of
member declarations. Such a requirement is too easy to overlook and too
fragile to maintain.

In the real world, NotDodgy would use a "smart" pointer to manage ptr's
allocation. A smart pointer would ensure that ptr's memory is properly
deallocated should it have been allocated before the exception was
thrown.

Greg

Nov 22 '05 #11

P: n/a
Greg wrote:
John Harrison wrote:
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.

I would note that this example is for illustrative purposes only, no
actual program would rely on something as fragile as the order of
member declarations. Such a requirement is too easy to overlook and too
fragile to maintain.


Absolutely, but Graham was looking for 'a particularly tricky memory
leak that's hard to spot', 'something that's a little unusual
or obscure' and 'Something that would be really easy to miss'.

Making pointer code exception safe is tricky. Another reason not to use
pointers of course. If I had to use pointers for some reason then I
would allocate memory in the body of the constructor.

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

This code will not leak memory irrespective of initialisation order issues.

john
Nov 22 '05 #12

P: n/a
I like it. Thanks a million.

G

Nov 22 '05 #13

This discussion thread is closed

Replies have been disabled for this discussion.