Memory leak due to waiting thread
-
I have an application in which a second (worker) thread is created using AfxBeginThread(). The execution of this thread can be stalled due to a WaitOnSingleObject(), which MAY never get signalled. In this situation, when the application main thread terminates, I get a memory leak as follows:- Detected memory leaks! Dumping objects -> strcore.cpp(118) : {78} normal block at 0x003011E0, 16 bytes long. Data: < D:\ > 01 00 00 00 03 00 00 00 03 00 00 00 44 3A 5C 00 strcore.cpp(118) : {77} normal block at 0x00301220, 59 bytes long. Data: < . Thre> 01 00 00 00 11 00 00 00 2E 00 00 00 54 68 72 65 thrdcore.cpp(166) : {71} client block at 0x003014C0, subtype 0, 112 bytes long. a CWinThread object at 003014C0, 112 bytes long If the WaitOnSingleObject gets signalled, then there is no memory leak. I have tried various things to get over this problem, but have had no success. How should I properly deal with a waiting thread to avoid the memory leak ? (Apologies if this is a "trivial" question to the more experienced "threaders" !!)
Doug
-
I have an application in which a second (worker) thread is created using AfxBeginThread(). The execution of this thread can be stalled due to a WaitOnSingleObject(), which MAY never get signalled. In this situation, when the application main thread terminates, I get a memory leak as follows:- Detected memory leaks! Dumping objects -> strcore.cpp(118) : {78} normal block at 0x003011E0, 16 bytes long. Data: < D:\ > 01 00 00 00 03 00 00 00 03 00 00 00 44 3A 5C 00 strcore.cpp(118) : {77} normal block at 0x00301220, 59 bytes long. Data: < . Thre> 01 00 00 00 11 00 00 00 2E 00 00 00 54 68 72 65 thrdcore.cpp(166) : {71} client block at 0x003014C0, subtype 0, 112 bytes long. a CWinThread object at 003014C0, 112 bytes long If the WaitOnSingleObject gets signalled, then there is no memory leak. I have tried various things to get over this problem, but have had no success. How should I properly deal with a waiting thread to avoid the memory leak ? (Apologies if this is a "trivial" question to the more experienced "threaders" !!)
Doug
Add a "Terminate" event and then do a WaitOnMultipleObjects() with the terminate event handle first in the array. When you need to terminate, set the terminate event and sleep at least 0 (to give the other thread a chance to run.) Have the thread then exit normally and it will do cleanup. A more sophisticated solution is to wait on the thread handle after you set the terminate event, though AfxBeginThread() makes this a bit tricky.
-
Add a "Terminate" event and then do a WaitOnMultipleObjects() with the terminate event handle first in the array. When you need to terminate, set the terminate event and sleep at least 0 (to give the other thread a chance to run.) Have the thread then exit normally and it will do cleanup. A more sophisticated solution is to wait on the thread handle after you set the terminate event, though AfxBeginThread() makes this a bit tricky.
Hi Joe, I had actually implemented your first solution already, except for the Sleep(0) - I NOW realise that there was a thread "race", which therefore still allowed failure. I also found that it works just as well with the terminate event handle in the second position in the array - have I missed something ? Many thanks for your help by the way !!
Doug
-
Hi Joe, I had actually implemented your first solution already, except for the Sleep(0) - I NOW realise that there was a thread "race", which therefore still allowed failure. I also found that it works just as well with the terminate event handle in the second position in the array - have I missed something ? Many thanks for your help by the way !!
Doug
I say put the terminate first because the wait processes objects in order. If the terminate event is last in the list and the previous events keep going signaled, you may never pick up that the terminate event is signaled (unless you check it after the WaitForMultipleObjects.)
-
I say put the terminate first because the wait processes objects in order. If the terminate event is last in the list and the previous events keep going signaled, you may never pick up that the terminate event is signaled (unless you check it after the WaitForMultipleObjects.)
Of course !! Thanks again for your help
Doug
-
Of course !! Thanks again for your help
Doug
Have a look here[^] for a more descriptive explanation of what Joe is talking about. You'll also find a lot of things that are Really Good To Know regarding multithreading in the article.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown