Die Another Day!

[retry]

This is what is happening:

The thread complets its job and dies by exiting the thread function but it tuns out that it doesn't actually die. When I exit application it GUI goes but I can still see it in Task Manager with 2 threads running. One is the main thread and 2nd is the communication thread (which I try to kill).

I walk this communication thread to the gate with debuger to make sure it exists and it does and returns from the thread function but it in fact doesn't die and blocks the application as well from terminating.

This happening on Windows XP home edition but not any other OS like Windows 200. Any suggestions or remarks on how to kill this thread? Btw I have the thread killing mechanism and the main thread signals this thread to exit which works fine but it that it doesn't actually die.

Any remarks, suggestions or welcome.

Thanks

[ovidiucucu]

If your rebellious communications thread(s) is a GUI thread, you must post WM_QUIT to terminate it.
See example below:
BOOL CMyApp::InitInstance()
{
// ...
m_pThread = (CMyThread*)AfxBeginThread( RUNTIME_CLASS(CMyThread) );
// ...
}

int CMyApp::ExitInstance()
{
// ...
m_pThread->PostThreadMessage( WM_QUIT, 0, 0 );
return CWinApp::ExitInstance();
}
If it is a worker thread, call ::TerminateThread API function.
However, just as an advice, for the communications, better use a GUI thread.

[retry]

I have tried the thread exit functions like AfxEndThread(), ExitThread() (haven't TerminateThread through). Its a worker thread.

The fact that the thread does actually exits and the thread function returns leaving a debug MFC message on output window "The thread 0x670 has exited with code 0 (0x0)". After this Spy++ determines that the thread is actually still running. What does this tell us? Why is the thread still running when the thread function is no longer running?

I am wondering if there is atleast any explanation to this behavior!

Thanks

[vicodin451]

At the point you have determined that the thread should not be executing code anymore, but it appears to still be alive, break into the debugger and use Debug | Threads to view the threads. Examine the call stack for each thread.


exists and it does and returns from the thread function
Watch the output window in the debugger for notification that "The thread 0xnnn has exited with code nn (0xnn)."

but it in fact doesn't die and blocks the application as well from terminatingYou watched it die. How can it keep the app from terminating? When the main thread of a process executes the CRT cleanup code, ExitProcess is called.The ExitProcess function ends a process and all its threads.


After this Spy++ determines that the thread is actually still running.

What are you looking at to determine this? Are you sure the threads being examined are your threads?

[retry]

When I debug the thread, the thread code doesn't block at all and and it executes normally and exists the thread at return statment just in the end of the thread function (I have plugged in w/o AfxEndThread(), ExitThread() at this point as well).

Thats why my question is, the thread does terminates normally from the code and I expect no problem to exist.

How do I determine that this thread is running and the application is not terminating due to this?

When the thread exits, it leaves the Thread ID on the output window. I simply examine the application with SPy++ (in process) and my application proess runs two threads, one of them matches the exited Thread ID, the other is obviously the main thread.

The application still remains in memory when I exit it, maybe because this one thread is blocking on something (but apparently not on my code) and the whole application may block on this thread?

It would be nice to know as what could be the reason the thread count doesn't go down when the thread does apparently terminate.

Thanks

[vicodin451]

Originally posted by retry
When I debug the thread, the thread code doesn't block at all and and it executes normally and exists the thread at return statment just in the end of the thread function (I have plugged in w/o AfxEndThread(), ExitThread() at this point as well).
At the point you have determined that the thread should not be executing code anymore, but it appears to still be alive, break into the debugger and use Debug | Threads to view the threads. Examine the call stack for each thread.


How do I determine that this thread is running and the application is not terminating due to this
Debug the application's exit routine. Walk the main thread to the ExitProcess call in the CRT source.


When the thread exits, it leaves the Thread ID on the output window. I simply examine the application with SPy++ (in process) and my application proess runs two threads, one of them matches the exited Thread ID, the other is obviously the main thread.
See the very first blurb of my response.

[Feneck]

I have not really the same problem but same error...
I have launch severals threads and they make their own works.

All treads use TRACE macro to make me help to debug application and understand all problems that can appear in multithread application.

Severals thread (T1) are creates by main tread. All of these thread create on thread (T2)...
So, at the same time, there are several T1 and T2 threads.

When T2 is terminated, the debugger write "The thread 0x---- has exited with code 0 (0x0)." but it is a direct access to the OutputDebug window because I use 'Extended Debugging Utility Set"
(url : http://www.codeguru.com/Cpp/V-S/debug/article.php/c4419#Configuration) that add timestamps in TRACE messages, this timestamp is not written in the message "The thread 0x---- has exited with code 0 (0x0).".

And then, when this thread dead (T2 type), the application deadlock, all is freeze.

My main Thread is blocked, but it done nothing, just display the dialog box (why other thread can block Main thread with no corelation ?)...
I suppose, TRACE function is not really thread safe, or there are some problems...I think it is the TRACE that make the deadlock => In release mode, no problem, in DEBUG mode without trace no problems too !

Another strange thing : When the the thread terminated, the application is very very slow, like if the terminated of the thread are bloking the main thread during die...

I don't know if i'm in a good way ... But it's really strange....

Do you found the fix of your problem ?

Stephane.

[Mick]

It's not clear whether you are using the debugger or tracing to a file, if it's the former, then...

http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/Q173/2/60.ASP&NoWebContent=1

[Feneck]

Yes, it is exactly this problem !!
Thanks a lot...

Finded a way to correct it....

Post in url : url : http://www.codeguru.com/Cpp/V-S/deb...9#Configuration).

[Andreas Masur]

[Moved thread]