Strange Deadlock while terminating a thread

[matze42]

Hi,

i encountered a strange error in my application.
As the whole code is quite too complex to post here, i try a short version
of the problem.

First, I have a thread, which calls an Execute-Function in a Plugin-Kind
class ( A user of our API is free to fill this Execute-Function with its own code ).
In this case the Execute-Function consists of an endless while-loop, without any sleep in it, just allocating a huge amount of memory ( I know, not very
sensfully, but the user is free to do this ).

Now i want to stop this thread:
I Send a Stop-Thread signal.
If the Execute-Function is programmed properly it should react on this signal and leave the Execute.
But in this case it does not.
Now i wait for a, lets say 5 seconds, and then i Terminate the Thread.

And now the obscure.
When i try to delete the Thread-Object i run in a deadlock in the heap.
( O.K.: I forgot: i'm using MVS7.NET under WinXP prof. - standard C++ Dll Project ).
I found, that is not a problem of the Debug-Heap ( Here i can see, where the thread hangs ). The problem also occurs in the release version.

Any ideas about that ?
Any hint is welcome.
Greetings,
Matze

[kuphryn]

Describe the stop signal and the process of which the thread receives and analyzes that signal.

Kuphryn

[wxuf]

Maybe the "execute function" has run over..

[matze42]

Hi kuphryn and wxuf,

thank you for reply.
I try to describe it with some (pseudo) code:

// The base class
class CBaseClass
{    
    virtual void Execute() = 0;

    // Has a pointer to the ThreadWrapper
    bool IsStopped()
    {
        return m_pThreadWrapperInst->IsStopped();
    };
};

// A User of our API is free to Derive from BaseClass and write its own execute
class CExecuteClass : public CBaseClass
{
    virtual void Execute()
    {
        // a proper execute should look like this
        while( ... && !IsStopped() ) ... 

        // not a proper execute and this is the problem
        while( ... ) // Some condition which never becomes true
        {
            ... Alloc huge amount of memory (about 10MB / s )
        }
    };
};

// a thread wrappe
class CThreadWrapper
{
    ...;

    unsigned ThreadHandlerProce
    {
        pExecuteClassInst->Execute();
    };

    //from extern
    void Stop()
    {
        //Lock Critical Section
        m_bStopped = true;
        //Unlock Critial Section
         
        if ( !WaitForStopped( 5 seconds ) )
        {
            // Terminate if not stopped
            Terminate();
        }        
    };
    
    bool IsStopped()
    {
        //Auto Lock Critical Section
        return m_bStopped;
    }

    // Stop Signal is a simple bool protected with a critical section
private:
    bool m_bStopped;
};

// And somewhere in the code
{
    //...

    pThreadWrapper->Stop();
    delete pThreadWrapper;
    // This is the described location, where it runs into the deadlock

    //...
}

.. hope this explains my problem a little bit more.

Is it possible, that the following happens?
When allocation/deallocating memory on the heap, the heap is locked.

-The "Execute" allocates memory and locks the heap.
-The Thread is terminated.
-The Heap keeps locked.
-At next allocation a deadlock occurs

By,
Matze

[kuphryn]

In this case, the key is in the waiting stage. Does the second while loop rely on the same break key?

Kuphryn

[matze42]

Hi kuphryn,

if you mean the part

if ( !WaitForStopped( 5 seconds ) )
        {
            // Terminate if not stopped
            Terminate();
        }

the answer is no.
Here i ask for the exit-code of the thread. i.e.

while( GetExitCode() != STILL_ACTIVE )
{
Sleep(50);
// check time waited yet
}

And generally it works perfectly.
In the described case it works, too.
But after waiting and then terminating the thread, it hangs in
the "delete" of the thread-object.

By,
Matze

[kuphryn]

Interesting. Walk through the deletion code. What line does it stop at?

Kuphryn

[matze42]

Hi Kuphryn,

first, thank you very much for your interest in this subject.
second, i did a little mistake in my last post.
sure it must be:

while( GetExitCode() == STILL_ACTIVE )
{
Sleep(50);
// check time waited yet
}

now to the place it hangs in the delete:

the file ( debug-version of course ): dbgdel.cpp
and the code

void operator delete(
        void *pUserData
        )
{
        _CrtMemBlockHeader * pHead;

        RTCCALLBACK(_RTC_Free_hook, (pUserData, 0));

        if (pUserData == NULL)
            return;

        _mlock(_HEAP_LOCK);  /* block other threads */ <--- Here ist hangs !!!
        __TRY

            /* get a pointer to memory block header */
            pHead = pHdr(pUserData);

             /* verify block type */
            _ASSERTE(_BLOCK_TYPE_IS_VALID(pHead->nBlockUse));

            _free_dbg( pUserData, pHead->nBlockUse );

        __FINALLY
            _munlock(_HEAP_LOCK);  /* release other threads */
        __END_TRY_FINALLY

        return;
}

I checked the code below, and found that _mlock simply enters a special critical section.
Because of this, my assumption is, that a earlier lock wasn't leaved by the terminated thread. So Entering the critical section isn't possible.

Strange Subject, isn't it ?

Bye,
Matze

[kuphryn]

Debugging thread deadlock via forum is difficult. Walk through the key sections of the thread and before and after the call to _mlock.

Kuphryn

[Arjay]

 if ( !WaitForStopped( 5 seconds ) )
         {
             // Terminate if not stopped
             Terminate();
         }

But after waiting and then terminating the thread, it hangs in
the "delete" of the thread-object.

How are you terminating the thread? Do you signal it to end via an event or do you use TerminateThread()? Also, I noticed that you have the m_bStopped param guarded with a critical section. What cs mechanism are you using? Native Win32 cs? CS wrapper class?

Arjay

[matze42]

Hi Arjay,

like described above i first try to signal the thread to finish itself, by setting the stop flag.
And then if its not ended in between 5 sec. i terminate it via TerminateThread.

The critical section is indeed a Win32 CriticalSection wrapper-class. But I'm using it for years and never encountered any problems with it, even in bigger applications with more threads.

I know that its very difficult to debug such a problem via the forum, threrefore i try to reproduce the problem with a small project, which i can post totally here.

Until then, thank you all for your interest,
By,
Matze

[Black_Daimond]

virtual void Execute()
    {
        // not a proper execute and this is the problem
        while( ... ) // Some condition which never becomes true
        {
            ... Alloc huge amount of memory (about 10MB / s )
        }
    };

i think the deadlocks comes from this place.When u send ur stop signal ,nothing catches it so it's not handled .After when u terminate the thread and want to delete it ,memory is still allocated and may used by the thread