[x264-devel] Fix clobbering of mutex/cvs

[pps .]

I downloaded x264 git a couple of days ago and I tried to use it on windows. It was always crashing if I used win-threads and backtrace was corrupted, I wasn't even able to see what caused it. Apparently, it crashed when calling some win-api.
Today I pulled the new fix (by Anton Mitrofanov, Commit:5c85e0a2b7992fcaab09418e3fcefc613cffc743) and the problem is gone.

When I tried to look into it, I saw some strange code:

int x264_pthread_mutex_lock( x264_pthread_mutex_t *mutex )
{
    static x264_pthread_mutex_t init = X264_PTHREAD_MUTEX_INITIALIZER;
    if( !memcmp( mutex, &init, sizeof(x264_pthread_mutex_t) ) )
        *mutex = thread_control.static_mutex;
    EnterCriticalSection( mutex );
    return 0;
}

As I understand, if some mutex wasn't initialized, it will be overwritten with the thread_control.static_mutex. How is that might make sense? Does that match regular pthread behavior? Is that sure that windows' CRITICAL_SECTION can be reused in that way? Internally it contains some opaque pointers/handlers CRITICAL_SECTION.hCrit or handlers to semaphores etc. It all depends on the OS version. In any case, the bible says that "A critical section object cannot be moved or copied": http://msdn.microsoft.com/en-us/library/ms683472%28v=VS.85%29.aspx . Which is enough to consider that win32thread.c/x264_pthread_mutex_lock is bad.

PS. no idea if that clobbering of mutex was related to that, but I had that impression that it was related to that code.


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20120312/6480c6c9/attachment.html>