BlogMatrix
 

wxMutexInternal bug?

edit David Janes 2004-06-18 15:29 UTC add comment  ·

In the Mac version of Jäger, I'm randomly getting crashes from deep within the wxPython code. The application run for several days without a crash, but crash it will eventually.

This is what I think the problem is but I'd like your feedback:

src/mac/thread.cpp

class wxMutexInternal
{
public:
    ...
    wxArrayLong m_waiters ;
    ...
};

wxMutexError wxMutexInternal::Lock()
{
    wxMacStCritical critical ;
    if ( UMASystemIsInitialized() )
    {
        OSErr err ;
        ThreadID current = kNoThreadID;
        err = ::MacGetCurrentThread(&current);
        // if we are not the owner, add this thread to the list of waiting threads, stop this thread
        // and invoke the scheduler to continue executing the owner's thread
        while ( m_owner != kNoThreadID && m_owner != current)
        {
            m_waiters.Add(current);
            err = ::SetThreadStateEndCritical(kCurrentThreadID, kStoppedThreadState, m_owner);
            err = ::ThreadBeginCritical();
        }
        m_owner = current;
    }
    m_locked++;

    return wxMUTEX_NO_ERROR;
}

You'll notice that the first time through, m_waiters is modified outside the critical section. This same variable is modified in the Unlock code within a critical section, indicating to me that this is the problem. Thoughts?

This is really a dealbreaker for shipping a super reliable version (i.e. non-Beta) version of Jäger. I had another idea of restarting Jäger whenever this happens, but there seems to be no way of trapping the EXC_BAD_ACCESS thrown by the Mach kernel like a normal UNIX bus error. Or is there?

Add Comment