The wild pointer to C + + memory leak

Writing this article is only for the purpose of memo.

Recently added to the software now a memory recycling mechanism (previously in some kind of memory only requested not released, this is not equal to memory leaks, because we know that the memory block in memory location)-a block within a certain time when there is no use to release it, to prevent slow memory growth.

There is no problem with the wild pointer because the memory has not been freed before. So I'm sure the pit-daddy thing starts with the memory release ... /Cry

Only after the memory release mechanism has been added, the software has a variety of crashes ...

Well, gossip less, straight to the subject.

A memory block is referenced in many places, once a place frees up memory, and other places are still quoted, the consequences ...

1.

At that time I thought this question is very simple, the typical wild pointer question ...

A reference count is added to the pointer to the memory block (a reference count is added once (atomic operation)), and the memory block is freed instead of the reference count minus one (atomic operation), and the reference count is reduced to 0 o'clock to release the memory ...

The spectators must have thought the problem would be solved satisfactorily. In fact... The pit-daddy thing is not over yet really just started ... /Cry/Cry/Cry

After adding the reference count, the program is much more stable than before, but basically every 1 hours will crash once ...

Then began to find a variety of problems ...

Later, the problem is found in the issue of resource release, see the following code:

int Release () {interlockeddecrement (&m_nrefcount); if (m_nrefcount <= 0) {
Delete this;}
else{
 　　　　　　  Do something
...
}
return (M_nrefcount);}

InterlockedDecrement is really an atomic operation, but the latter statement is not, when multithreading is present, it is possible that interlockedderement will be executed two times after the first if statement will be executed (if you do not understand the thought, haha), The problem is that it causes the memory block to be freed two times ...

2.

A fall into your wit ... And then the code changed to look like this.

HRESULT Release () {int refcount = InterlockedDecrement (&m_nrefcount); if (refcount <= 0) {
Delete this;}
else{


}
return (M_nrefcount);}

This will not be affected by the reference count after calling Interlockedderement ... At least not repeat delete yourself ...

3.

After this modification the software is indeed more stable, running 5-6 hours no problem ... But... After 5-6 hours, the software still crashes, still crashes, still crashes ...

Why is it? At that time is also a variety of don't think ... Later, after a long way of pondering and various extreme debugging methods, finally found the problem:

Let's see how I add References:

ULONG AddRef (void) {return interlockedincrement (&m_nrefcount);
}

It turns out that my reference to memory is not the first reference and then release, but the reference and release interspersed use, because it is multi-threading, while increasing the reference and resource release is not mutually exclusive execution, it is possible to execute simultaneously, while executing, while executing ...

When executing at the same time there will be a minimum probability that the reference count is reduced to 0, the DELETE statement is executed by the gap, there is a reference count plus one action, so that the memory block appears to have not been released (the reference count of 1) has actually been released, which produced a wild pointer, produced a wild pointer, the field of the hand!

Found the problem, but not the solution ... Because there is no more lock in the release and AddRef, because there are too many places to use it, the effect of efficiency does not mean that it may lead to deadlocks.

It was only possible to add locks in places where this could happen, but it was not a good place to be able to produce such a situation.

Then the problem was solved satisfactorily ...

The wild pointer to C + + memory leak