c++ 导致内存泄露的一些小问题与解决方法
2012-03-13 08:53
716 查看
Recently i had a project which had some of the worst memory leaks in C++ i’ve ever had to deal with. It had just about every memory leak problem you could think of, all of which could have been solved with a little bit of planning.
Using tools such as Valgrind or
Instruments surely helps, but they can only help you so much.
So if you have a nightmarish C++ project with memory leaks, heres a few ways in which you can solve them.
Which can be solved by:
Which can be solved by deleting the object before re-assigning:
If you destroy an instance of Woo both ~Woo and ~Foo will be called. Only it wont: only~Woo will be called. Anything you free in~Foo will never be freed.
So if you want ~Foo to be called too, the destructor for Foo needs to be virtual, i.e.:
Object
*foo,
*child1,*child2
Now when do we delete foo? If we make child1 or child2 delete it, we’ll probably get a crash when we delete
foo twice. If we delete it elsewhere, how do we know child1 or
child2 aren’t still using it?
One possible solution is to use a reference counting system like in Objective C, so when we reach 0 we delete the object:
class Object
{
Object*
retain()
{
retainCount++;
// object is being used return
this;
}
void release()
{ --retainCount;
// object is no longer being used
if (retainCount
<= 0)
delete this;
}
virtual ~Object()
{ if
(parent)
parent->release();
}
Object *parent;
}; // ...
Object *foo,
*child1,
*child2;
foo = new
Object();
child1 = new
Object();
child1->parent
= foo->retain();
// object is being used by child1
child2 = new
Object(foo);
child1->parent
= foo->retain();
// object is being used by child2
If you want to be more fancy you can make a smart pointer class, e.g.
// Modified Object
class Object
{
Object* retain()
{
retainCount++;
return this;
}
void release()
{
--retainCount;
if (retainCount
<= 0)
delete this;
}
virtual ~Object()
{
parent =
NULL;
}
ObjectReference parent;
}; // The smart pointer
class ObjectReference
{
public:
// Constructor
ObjectReference()
{
object = NULL;
} // Assignment initializer
ObjectReference(const
ObjectReference &ref)
{
object = ref.object
? ref.object->retain()
: NULL;
} // Assignment operator
ObjectReference&
operator=(const
ObjectReference &ref)
{
if (object)
object->release();
object = ref.object
? ref.object->retain()
: NULL;
return *this;
} // Pointer operator
operator Object*()
{
return object;
}
Object *object;
// reference to Object };
// ...
Object *foo,
*child1,
*child2;
foo = new
Object();
child1 =
new Object();
child1->parent
= foo;
// automagically retains
foo child2 =
new Object();
child1->parent
= foo;
// automagically retains foo
Beware however that when you get a circular reference your objects may never be released using this method.
One way of solving this is to keep track of where you retain and release objects
class Object
{
Object* retain(char
*file=NULL,
int line=0,
char *owner=NULL,
int addr=0)
{
retainCount++;
if (owner)
printf("%x: retain (%i) [%s @ %i] OWNER %s[%x]",
this, retainCount,
file ? file
: "", line,
owner, addr);
else
printf("%x: retain (%i) [%s @ %i]",
this, retainCount,
file ? file
: "", line);
return this;
}
void release(char
*file=NULL,
int line=0,
char *owner
= NULL,
int addr=0)
{ -
-retainCount;
if (owner)
printf("%x: release (%i) [%s @ %i] OWNER %s[%x]",
this, retainCount,file
? file :
"", line,
owner, addr);
else
printf("%x: release (%i) [%s @ %i]",
this, retainCount,file
? file :
"", line);
if (retainCount
<= 0)
delete this;
} // ... };
// ...
Object *foo,
*child1,
*child2;
foo = new
Object();
child1 = new
Object();
child1->parent
= foo->retain(__FILE__,
__LINE__, "Object",
child1);
child2 = new
Object(foo);
child1->parent
= foo->retain(__FILE__,
__LINE__, "Object",
child2);
Then you can simply examine your logs and spot the problematic line of code for that extra release or retain.
class Entity
{
public: float
mNextThink;
Entity();
void think();
};
Entity::Entity()
{
}
What is wrong with this? Well say we have some code like this….
for (int
i=0;
i<mEntities.size();
i++)
{
if (smCurrentTime
>= mEntities[i]->mNextThink)
mEntities[i]->think();
}
Then think may never be called, since mNextThink is never initialized, so its value will be undefined. It could be 0, it could be -10000. Who knows. The solution is simple:
Entity::Entity()
:
mNextThink(0)
// set a default value
{
}
With all of your memory leaks solved, you should now be able to sleep better.
Using tools such as Valgrind or
Instruments surely helps, but they can only help you so much.
So if you have a nightmarish C++ project with memory leaks, heres a few ways in which you can solve them.
Stage 1: Forgetfulness
We start off with a simple case: when you make an object but never delete it. e.g.:Object *foo = new Object(); // foo never deleted
Which can be solved by:
delete foo; // <<< delete the object
Stage 2: Garbage Collection
Sometimes you have a pointer to an object which is re-assigned at one point, but the old object is never deleted.Object *foo; foo = new Object(); // ... later on ... foo = new Object();
Which can be solved by deleting the object before re-assigning:
Object *foo; foo = new Object(); // ... later on ... delete foo; // <<< delete the old object foo = new Object();
Stage 3: Destructors
Some people assume if you make a couple of classes like this:class Foo { Foo(); ~Foo(); }; class Woo : public Foo { Woo(); ~Woo(); };
If you destroy an instance of Woo both ~Woo and ~Foo will be called. Only it wont: only~Woo will be called. Anything you free in~Foo will never be freed.
So if you want ~Foo to be called too, the destructor for Foo needs to be virtual, i.e.:
class Foo { Foo(); virtual ~Foo(); // <<< };
Stage 4: Spaghetti
Things start getting complicated when you have objects which can be referenced by multiple objects. For example:Object
*foo,
*child1,*child2
foo= new Object();
child1= new Object();
child1->parent= foo;
child2= new Object(foo);
child1->parent= foo;
Now when do we delete foo? If we make child1 or child2 delete it, we’ll probably get a crash when we delete
foo twice. If we delete it elsewhere, how do we know child1 or
child2 aren’t still using it?
One possible solution is to use a reference counting system like in Objective C, so when we reach 0 we delete the object:
class Object
{
Object*
retain()
{
retainCount++;
// object is being used return
this;
}
void release()
{ --retainCount;
// object is no longer being used
if (retainCount
<= 0)
delete this;
}
virtual ~Object()
{ if
(parent)
parent->release();
}
Object *parent;
}; // ...
Object *foo,
*child1,
*child2;
foo = new
Object();
child1 = new
Object();
child1->parent
= foo->retain();
// object is being used by child1
child2 = new
Object(foo);
child1->parent
= foo->retain();
// object is being used by child2
If you want to be more fancy you can make a smart pointer class, e.g.
// Modified Object
class Object
{
Object* retain()
{
retainCount++;
return this;
}
void release()
{
--retainCount;
if (retainCount
<= 0)
delete this;
}
virtual ~Object()
{
parent =
NULL;
}
ObjectReference parent;
}; // The smart pointer
class ObjectReference
{
public:
// Constructor
ObjectReference()
{
object = NULL;
} // Assignment initializer
ObjectReference(const
ObjectReference &ref)
{
object = ref.object
? ref.object->retain()
: NULL;
} // Assignment operator
ObjectReference&
operator=(const
ObjectReference &ref)
{
if (object)
object->release();
object = ref.object
? ref.object->retain()
: NULL;
return *this;
} // Pointer operator
operator Object*()
{
return object;
}
Object *object;
// reference to Object };
// ...
Object *foo,
*child1,
*child2;
foo = new
Object();
child1 =
new Object();
child1->parent
= foo;
// automagically retains
foo child2 =
new Object();
child1->parent
= foo;
// automagically retains foo
Beware however that when you get a circular reference your objects may never be released using this method.
Stage 5: Runaway Spaghetti
Even if you have a reference counting system, you might encounter situations where you release or retain objects too much. Typically memory leak tools only tell you where objects were allocated, not who the retain/release culprit is.One way of solving this is to keep track of where you retain and release objects
class Object
{
Object* retain(char
*file=NULL,
int line=0,
char *owner=NULL,
int addr=0)
{
retainCount++;
if (owner)
printf("%x: retain (%i) [%s @ %i] OWNER %s[%x]",
this, retainCount,
file ? file
: "", line,
owner, addr);
else
printf("%x: retain (%i) [%s @ %i]",
this, retainCount,
file ? file
: "", line);
return this;
}
void release(char
*file=NULL,
int line=0,
char *owner
= NULL,
int addr=0)
{ -
-retainCount;
if (owner)
printf("%x: release (%i) [%s @ %i] OWNER %s[%x]",
this, retainCount,file
? file :
"", line,
owner, addr);
else
printf("%x: release (%i) [%s @ %i]",
this, retainCount,file
? file :
"", line);
if (retainCount
<= 0)
delete this;
} // ... };
// ...
Object *foo,
*child1,
*child2;
foo = new
Object();
child1 = new
Object();
child1->parent
= foo->retain(__FILE__,
__LINE__, "Object",
child1);
child2 = new
Object(foo);
child1->parent
= foo->retain(__FILE__,
__LINE__, "Object",
child2);
Then you can simply examine your logs and spot the problematic line of code for that extra release or retain.
Final boss
Of course once you have solved all of your leaks, you might find you bump into the arch nemesis: Memory Corruption. Specifically, this:class Entity
{
public: float
mNextThink;
Entity();
void think();
};
Entity::Entity()
{
}
What is wrong with this? Well say we have some code like this….
for (int
i=0;
i<mEntities.size();
i++)
{
if (smCurrentTime
>= mEntities[i]->mNextThink)
mEntities[i]->think();
}
Then think may never be called, since mNextThink is never initialized, so its value will be undefined. It could be 0, it could be -10000. Who knows. The solution is simple:
Entity::Entity()
:
mNextThink(0)
// set a default value
{
}
With all of your memory leaks solved, you should now be able to sleep better.
相关文章推荐
- C++ vector变量等导致内存泄露问题的解决方法
- 使用Handler导致内存泄露的解决方法
- JNI接口中jstring导致内存泄露问题的解决
- C++技术问题总结-第15篇 内存泄露有哪些方法定位,崩溃有哪些方法定位
- QuickReport报表Prepare之后造成内存泄露问题的解决方法
- C++内存越界问题及解决方法
- Java中典型的内存泄露问题和解决方法
- javascript内存泄露问题的解决方法和辅助工具
- win7最大内存设置问题,导致系统无法启动的解决方法
- C# Webbrowser使用加载页面多少了内存泄露问题解决方法汇总
- PHP CURL 内存泄露问题解决方法
- Java中典型的内存泄露问题和解决方法
- Flex中Module的使用以及内存泄露问题解决方法
- C++解决大数组栈内存不够问题的方法分析
- performSelectorInBackground 导致内存泄露的解决方法
- QT中使用槽函数来关闭窗口,导致内存泄露的问题以及解决办法
- GDI对象错误:CBRUSH释放、CreateSolidBrush的内存释放与内存泄露问题及其解决方法
- ATS插件开发中内存泄露问题的解决方法探讨
- tomcat服务器内存不足导致的无法连接服务器问题解决方法
- Java中典型的内存泄露问题和解决方法