memory in the wxThread

If you are using the main C++ distribution of wxWidgets, Feel free to ask any question related to wxWidgets development here. This means questions regarding to C++ and wxWidgets, not compile problems.
Post Reply
xpz
Earned a small fee
Earned a small fee
Posts: 10
Joined: Sun Sep 23, 2007 10:51 pm

memory in the wxThread

Post by xpz » Thu May 14, 2009 8:01 pm

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.

TrV
Ultimate wxWidgets Guru
Ultimate wxWidgets Guru
Posts: 630
Joined: Wed Jul 04, 2007 1:12 pm

Post by TrV » Thu May 14, 2009 8:07 pm

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

AkiraDev
Knows some wx things
Knows some wx things
Posts: 48
Joined: Tue May 24, 2005 9:13 am

Post by AkiraDev » Thu May 14, 2009 9:35 pm

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.
Back, just not as often

Windows Vista SP1, Ubuntu 8.04
MinGW 3.4.5, GCC 4.2.1
Code::Blocks
wxWidgets 2.8.9

xpz
Earned a small fee
Earned a small fee
Posts: 10
Joined: Sun Sep 23, 2007 10:51 pm

Post by xpz » Tue May 26, 2009 8:27 pm

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.

Manatax
Knows some wx things
Knows some wx things
Posts: 37
Joined: Fri Feb 06, 2009 9:28 pm

Post by Manatax » Wed May 27, 2009 12:07 am

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?
"If it ain't broken... give it a little more time... it will break eventually..."

Muetdhiver
Super wx Problem Solver
Super wx Problem Solver
Posts: 323
Joined: Sun Jun 08, 2008 11:59 am
Location: Bordeaux, France

Post by Muetdhiver » Wed May 27, 2009 7:38 am

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.
OS: Ubuntu 11.10
Compiler: g++ 4.6.1 (Eclipse CDT Indigo)
wxWidgets: 2.9.3

Manatax
Knows some wx things
Knows some wx things
Posts: 37
Joined: Fri Feb 06, 2009 9:28 pm

Post by Manatax » Wed May 27, 2009 1:30 pm

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.
"If it ain't broken... give it a little more time... it will break eventually..."

Muetdhiver
Super wx Problem Solver
Super wx Problem Solver
Posts: 323
Joined: Sun Jun 08, 2008 11:59 am
Location: Bordeaux, France

Post by Muetdhiver » Thu May 28, 2009 8:08 am

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.
OS: Ubuntu 11.10
Compiler: g++ 4.6.1 (Eclipse CDT Indigo)
wxWidgets: 2.9.3

xpz
Earned a small fee
Earned a small fee
Posts: 10
Joined: Sun Sep 23, 2007 10:51 pm

Post by xpz » Sat May 30, 2009 3:21 am

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.

Auria
Site Admin
Site Admin
Posts: 6695
Joined: Thu Sep 28, 2006 12:23 am
Contact:

Post by Auria » Sat May 30, 2009 2:20 pm

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
"Keyboard not detected. Press F1 to continue"
-- Windows

Post Reply