Thread Shutdown Problems Under Win32

[Mike Hogan]

I've successfully integrated ZThread into an existing Windows XP application. They work fine, but I can't shut them down without crashing or hanging.

If I allow the runnable task to run to completion (it notes a flag which indicates it should break out of its main loop) I get the following ZThread debugging prints:

Thread joining...
Thread exiting...
insertPendingThread()
1 pending-thread added.

...then it crashes.

Below is the call stack, which looks a complete mess in this tiny window but might come out alright anyway.

If I don't set the flag so the task doesn't break out of its loop, the program reaches the end of main() but then hangs waiting for the thread to complete.

If I try to force the threads to stop, either by deleting the runnable object or by calling cancel() (is that what it's for?), I just get a slightly different crash.

Hope somebody can help!

Cheers,

Mike

     ntdll.dll!77f767cd()    
     ntdll.dll!77f6a6a0()    
     kernel32.dll!77e6c75a()    
>    msvcr70d.dll!_CrtIsValidHeapPointer(const void * pUserData=0x00954ab8)  Line 1807    C
     msvcr70d.dll!_free_dbg_lk(void * pUserData=0x00954ab8, int nBlockUse=0x00000001)  Line 1132 + 0x9    C
     msvcr70d.dll!_free_dbg(void * pUserData=0x00954ab8, int nBlockUse=0x00000001)  Line 1070 + 0xd    C
     msvcr70d.dll!operator delete(void * pUserData=0x00954ab8)  Line 53 + 0x10    C++
     ZThread.dll!ZThread::AtomicCount::`scalar deleting destructor'()  + 0x3e    C++
     ZThread.dll!ZThread::CountedPtr<ZThread::Runnable,ZThread::AtomicCount>::~CountedPtr<ZThread::Runnable,ZThread::AtomicCount>()  Line 106 + 0x2d    C++
     ZThread.dll!ZThread::Task::~Task()  + 0x2b    C++
     ZThread.dll!ZThread::ThreadImpl::dispatch(ZThread::ThreadImpl * parent=0x003b62f8, ZThread::ThreadImpl * impl=0x003b61f8, ZThread::Task task={...})  Line 451 + 0xf    C++
     ZThread.dll!ZThread::`anonymous namespace'::Launcher::run()  Line 48 + 0x30    C++
     ZThread.dll!ZThread::ThreadOps::_dispatch(void * arg=0x0012f630)  Line 183 + 0xd    C++
     msvcr70d.dll!_threadstartex(void * ptd=0x003b65b8)  Line 241 + 0xd    C
     kernel32.dll!77e7d33b()    

[Eric Crahen]

Hi Mike,

The problem is that although the Thread object may go out of scope itself, the task its using is still running. Which is fine; but your code needs to be structed in such a way that the task does not access resources that have gone out of scope.

I'll just describe the general situation. Its hard to be precise about something w/o code to show whats happening.

Setting the flag may cause your task to exit, but it will exit *eventually*, not immediately. So when main() exits and things start to get cleaned up your task is probably still going and you end up accessing invalid memory. (an example of things that can possibly become invalid when main() exits would be anything that was on the stack, or static objects)

Also, you don't need a separate flag, you could use Thread::interrupt()/Thread::interrupted() to accomplish the same thing your flag does (from the sound of it)

[Mike Hogan]

Thanks for the pointers, Eric.

My most recent attempt to sort out this problem was to cut and paste the sample code from the documentation for Thread(); - the stuff that prints "Hello from the main thread", etc.

This has the same problem, so I wonder if I've got some sort of build problem.

By inserting sleeps in a variety of places in the main thread and the subthread, I've discovered that if the subthread closes first, the program crashes, apparently in the destructor ~Task(), as in my program, while if the main thread completes first, the program hangs, as originally described, at

  inline STATE wait() {
    return wait(0);
  }

Do you think this might be related to some sort of build error?

Cheers,

Mike

[Anonymous]

Hi Mike,

I have exactly the same problem like you. Do you have any solution for it? Version 2.2.10 works fine without any problems.

best regards

wolfgang

[Noam Hoffer]

I have got the same problem.
any solution?

[Noam Hoffer]

I have also noticed that this happens because the destructor of CountedPtr is called twice.

[Anonymous]

For example you have an infinite loop inside a thread.
Then you need to force a thread run after cancellation and then check whether this thread has been canceled (using isCanceled).  Then you can break from your infinite loop

Regards,

Alex Narinsky