[vlc-devel] [PATCH] darwin/thread: Ignore vlc_mutex_unlock failures

Marvin Scholz epirat07 at gmail.com
Mon Oct 28 21:35:49 CET 2019

On 28 Oct 2019, at 18:46, Rémi Denis-Courmont wrote:

> Le maanantaina 28. lokakuuta 2019, 19.24.44 EET Marvin Scholz a écrit 
> :
>> macOS pthread implementation for pthread_cond_wait is buggy, causing
>> sometimes the mutex to not be locked when running thread cancellation
>> cleanup handlers.
>> This causes random failures of vlc_mutex_unlock, as the cancellation
>> cleanup handler does not hold a lock on the mutex in rare cases.
> This won't work:
> 1) Darwin does not define unlocking a mutex by a thread that did not 
> lock it:
> "Calling pthread_mutex_unlock with a mutex that the calling thread 
> does not
> hold will result in undefined behavior." So you cannot simply assume 
> that it
> will return an error and have no side effects; it probably only works 
> that way
> on sunny day cases.
> 2) Even if Darwin did provide that guarantee, this would cause data 
> races if
> the calling thread actually relied on the mutex being locked to access 
> lock-
> protected data.

Hi, thanks for the review.
I am aware of these issues, the intention of this is just to make debug 
builds on macOS work again without randomly crashing all the time.

The underlying issue exists since several years, this patch changes 
nothing in
that regard of how we behave in release builds, all it does is help 
to properly test stuff without unrelated failures with debug-enabled 
Additionally it solves a lot of „random“ test failures, where it is 
impossible to disable these assertions, even in non-debug mode.

Of course if you have a better idea how to workaround this issue, I 
would be
happy to do it in a better way.

> -- 
> Rémi Denis-Courmont
> http://www.remlab.net/
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel

More information about the vlc-devel mailing list