<div dir="ltr">
<div>We're seeing an issue with ManagedStaticMutex. There is a
race condition between mutex_init_flag and the call_once usage in
getManagedStaticMutex, at least on MSVC 2017.</div><div><br></div><div>The sequence of operations we see during startup are as follows:</div><div><br></div><div>1. The first global ManagedStatic initializes, causing getManagedStaticMutex to call initializeMutex through std::call_once</div><div>2.
Some N number of additional global ManagedStatic initialize, where
getManagedStaticMutex skips initializeMutex since it has already been
called</div><div>3. The global constructor for "mutex_init_flag" runs, resetting the flag indicating the call has already been made</div><div>4.
Another global ManagedStatic initializes, causing getManagedStaticMutex
to be called, but this time initializeMutex is run since the
mutex_init_flag flag was reset</div><div><br></div><div>After (4), the
original ManagedStaticMutex is leaked. Additionally, (1) and (2) are
operating on an uninitialized global variable.<br></div><div><br></div><div>As
a fix, is there anything wrong with making mutex_init_flag
function-local in getManagedStaticMutex? Its only use is in that
function, and this would guarantee mutex_init_flag is initialized before
use.</div>
<br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div></div></div>