Ranting and Roaring

2004/06/18

wxMutexInternal bug?

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?

Powered by WordPress