wxWidgets Discussion Forum

For the memory allocated in a detached thread, I am wondering when the momory will be returned to system after the thread finish.

Because my thread allocate 1.1G memory. After the thread end, the task manager still shows my application use 1.2G memory, it means the thread don't return memory to the system even it kill itself after it finish.

Can anybody know the reason? Whether there is a way to let the thread return the momory to system when it finish.

Thanks in advance.

Are you sur every "new" in thread has its "delete" ?

It seems to be a good idea to always make the main thread wait (for example, at wxFrame::OnClose()) until all the other threads have been deleted.
If this doesn't help, I would suspect the wxThread::Entry() entry points. Check that they all end deterministically.

PS: wxThread::Kill() usually is a bad idea, rely on wxThread::Delete() instead.

TrV wrote:Are you sur every "new" in thread has its "delete" ?

I am sure the deconstrcutor of thread delete all "new" memory. But some data use stl::vector<> to allocate some temporary buffer, but this buffer is not as larger as 50 Mbytes. Another thing is we use blitz to allocate big memory, the blitz use smart-pointer, I do not whether it is the reason.

xpz wrote:

TrV wrote:Are you sur every "new" in thread has its "delete" ?

I am sure the deconstrcutor of thread delete all "new" memory. But some data use stl::vector<> to allocate some temporary buffer, but this buffer is not as larger as 50 Mbytes. Another thing is we use blitz to allocate big memory, the blitz use smart-pointer, I do not whether it is the reason.

From what you say, the thread is not being deconstructed... Ergo, it is never finishing...
Is the thread mainly a cycle or a cascade?
Is the thread's constructor created by you or the compiler?

Manatax wrote:
From what you say, the thread is not being deconstructed... Ergo, it is never finishing...

Yes it did, since it is a detached thread. When over, the thread class is deleted, all subcomponents used in this thread must release their memory too.

xpz your problem seems hard to solve without a piece of code.
Nota: there is no problem with temporary buffers represented by std::vector.
Size allocated for such a structure is 4 bytes plus the data contained in, and a local std::vector will automatically be cleared when the block ends.

Or maybe it is a vector with object pointers instead of standard types, in this case they are not deallocated automatically, and you need to do it.

What I'll try in this case:
Try to comment portion of code wich are related to these temporary vectors. If it is not working, try to comment your code related to blitz (your smart pointers).

By commenting several portions of code, you will find the part of code that makes your memory leaks.

With regards,
Alexandre.

Muetdhiver wrote:

Manatax wrote:
From what you say, the thread is not being deconstructed... Ergo, it is never finishing...

Yes it did, since it is a detached thread. When over, the thread class is deleted, all subcomponents used in this thread must release their memory too.

xpz your problem seems hard to solve without a piece of code.
Nota: there is no problem with temporary buffers represented by std::vector.
Size allocated for such a structure is 4 bytes plus the data contained in, and a local std::vector will automatically be cleared when the block ends.

Or maybe it is a vector with object pointers instead of standard types, in this case they are not deallocated automatically, and you need to do it.

What I'll try in this case:
Try to comment portion of code wich are related to these temporary vectors. If it is not working, try to comment your code related to blitz (your smart pointers).

By commenting several portions of code, you will find the part of code that makes your memory leaks.

With regards,
Alexandre.

I'm sorry to disappoint you Alex, but a detached thread is still a thread... and as such, needs a proper logic to go from A to B... failing to produce that continued line will keep the thread alive indefinitely... but I agree with the fact that code needs to be exposed in order to further analyze the issue.

Ok ok but I was figuring out that this thread ended correctly as xpz mentionned it:

After the thread end, the task manager still shows my application use...

In the other case, you're right, memory is not released until the thread is closed.

Thanks for the help.

Currently, after trying many methods. We can sure now that part of no-release memory problem comes from blitz, but it's not all. Because after forcing blitz release all memory, the application still keep about 200M memory, but it is much better than 1.1G situation.

For the problem of whether the thread is really end, we can sure that. Because in debuging, we can reach thread deconstructor in the code.

Additionally, we also can sure that is not memory leak problem. Because the visual studio do not report any memory leak.

Might it simply be some pooling thing? Some library (or the system, or some part of the standard part library) might just retain some memory for re-use later without needing to re-allocate it. When searching for leaks this is quite often a thing people meet