WaitForSingleObject blocked whereas a thread has returned

[Guest]

Hello,

When closing my multithread application, before stopping the main thread I
wait, in this main thread, for a secondary thread to exit. I use for it the
function WaitForSingleObject which never end.

When debugging I can check that this secondary thread is returning zero and
exiting but by using spy++ I can see that this thread is still existing.

What can prevent this thread to terminate whereas this thread as returned
zero ?


Code sample :

HANDLE hThreadInterrogationPorte;

class CCNR_FonctionsDeBaseCN
{

(...)

static DWORD WINAPI ThreadInterrogationPorte(LPVOID lpParam);

(...)

}

DWORD WINAPI CCNR_FonctionsDeBaseCN::ThreadInterrogationPorte(LPVOID lpParam)
{
(...)
return 0;
}


CCNR_FonctionsDeBaseCN::CCNR_FonctionsDeBaseCN(CString PathOfCurrentDir)
{

(...)

DWORD ThreadId;

m_ParamCycleInterrogationPorte.hThreadInterrogationPorte =
CreateThread(
NULL, //LPSECURITY_ATTRIBUTES
lpThreadAttributes,
0, //SIZE_T dwStackSize,
&ThreadInterrogationPorte, //LPTHREAD_START_ROUTINE lpStartAddress,
&m_ParamCycleInterrogationPorte, //LPVOID lpParameter,
0, //Run immediately DWORD dwCreationFlags,
&ThreadId //LPDWORD lpThreadId
);

(...)

}

CCNR_FonctionsDeBaseCN::~CCNR_FonctionsDeBaseCN()
{

(...)

if(m_ParamCycleInterrogationPorte.hThreadInterrogationPorte != NULL)
WaitForSingleObject(m_ParamCycleInterrogationPorte.hThreadInterrogationPorte,INFINITE);

(...)
}

Best regards

JsCHarly

 

[Carl Daniel [VC++ MVP]]

Hello,

When closing my multithread application, before stopping the main
thread I
wait, in this main thread, for a secondary thread to exit. I use for
it the
function WaitForSingleObject which never end.

When debugging I can check that this secondary thread is returning
zero and
exiting but by using spy++ I can see that this thread is still
existing.

What can prevent this thread to terminate whereas this thread as
returned
zero ?

The thread object will continue to exist until all handles to the thread
have been closed. The thread can't run anymore in this state, but it does
still exist.

-cd

 

[Jochen Kalmbach [MVP]]

Hi Carl!

The thread object will continue to exist until all handles to the thread
have been closed. The thread can't run anymore in this state, but it does
still exist.

But the thread-handle will be signaled if the the thread has terminated.

But it seems that for some reason the thread has not terminated.

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

 

[Carl Daniel [VC++ MVP]]

Hi Carl!


But the thread-handle will be signaled if the the thread has
terminated.
But it seems that for some reason the thread has not terminated.

If it has returned from it's thread main function but hasn't terminated, I'd
guess it's somehow blocked in the CRT shutdown code. I'd be suspicious of a
corrupt heap state of some sort. I'd also try inserting a call to
TerminateThread to forcibly kill the thread & see what happens - that's not
the solution, but it might be illuminating.

-cd

 

[Guest]

Hello,

I've tried to use TerminateThread and now the terminated thread is signaled.

You said that the terminated thread may be non signaled because of a corrupt
heap state of some sort.

In debug mode Visual studio detect no leak of memory or other problem.
What can I do to detect the cause of this problem ?


JsCHarly

 

[Carl Daniel [VC++ MVP]]

Hello,

I've tried to use TerminateThread and now the terminated thread is
signaled.

You said that the terminated thread may be non signaled because of a
corrupt heap state of some sort.

In debug mode Visual studio detect no leak of memory or other problem.
What can I do to detect the cause of this problem ?

That's consistent with the thread being blocked. The CRT has some shared
state, and uses windows synchronization mechanisms to access that state (a
Mutex, if I recall correctly). I suspect that the thread is blocked trying
to get access to that shared state, but due to data corruption elsewhere,
the thread that owns the shared state is either also blocked or has
terminated improperly.

My first angle of attack would be to attach a debugger and attempt to
examine the stack of the blocked thread to see if you can work out where
exactly it's blocked.

If you have access to such a tool, you might try running the code through a
static analyzer like Purify or the /analyze option of VC++ 2005 Team Edition
to see if they can catch anything. You might also try running the code under
a dynamic analyzer like Bounds Checker to see if they catch anything.

-cd