title: Boost.Thread Assertion/Crash on Windows during win32::WaitForSingleObject
body: <p>I have a rarely occurring issue in my code in which an assertion is triggered, involving the Boost.Thread library. I haven't been able to reproduce this issue using a stand-alone example, and I don't really know what is causing it, so it's hard to provide a sample case. I am hoping that anybody familiar with the internals on boost.thread may be able to help.</p>
  
  <p>Here is what I know:</p>
  
  <ul>
  <li>The problem occurs when a <code>boost::lock_guard&lt;boost::recursive_mutex&gt;</code> (or variations of unique_lock and normal non-recursive mutex) is declared.</li>
  <li>It happens in a handler function for Boost.Asio. On the stack is the thread that does <code>io_service::run</code>, a bunch of glue to call the Asio callback function, followed by my callback function (triggered by an async_write call). The first line of that function is the declaration of the <code>lock_guard&lt;&gt;</code> which is causing the problem.</li>
  <li><code>this</code> inside of my function is valid, and has not been deleted or anything like that. The debugger shows that it points to valid data. The mutex that is being locked in my <code>handle_write</code> function also guards against deletion of the memory that the handling function uses.</li>
  <li>This works fine, I'd say 9,999 times out of 10,000, with heavy multi-threaded usage going on. The problem occurs with the same frequency if I tone down the number of threads used by the application to just one thread which handles Asio run() calls, and a main UI thread.</li>
  <li>The first line of my code calls the <code>lock()</code> method of the mutex (in the ctor of <code>boost::unique_lock&lt;&gt;</code>), then calls <code>lock()</code> in <code>boost::detail::basic_recursive_mutex_impl</code>, which calls the <code>lock()</code> method of <code>boost::detail::basic_timed_mutex</code>.</li>
  <li><p>In Boost 1.46, the assertion (<code>BOOST_VERIFY</code>) is on line 78 of basic_timed_mutex.hpp, which calls win32::WaitForSingleObject:</p>
  
  <pre><code>do
  {
      BOOST_VERIFY(win32::WaitForSingleObject(
                        sem,::boost::detail::win32::infinite)==0);
      clear_waiting_and_try_lock(old_count);
      lock_acquired=!(old_count&amp;lock_flag_value);
  }
  while(!lock_acquired);
  </code></pre></li>
  <li>At the time the Boost.Thread code is waiting to acquire a lock on the mutex (what this code path that uses <code>WaitForSingleObject</code>) does, no other thread is holding the mutex (at least at the time the assertion occurs, and can be examined in the debugger). This is odd because it should be able to obtain the lock without having to wait for another thread to relinquish control.</li>
  <li>Things look very odd, examining the members of the mutex. These are the values of all of the local and member variables (unless otherwise noted, they are the same every time this happens):
  <ul>
  <li><code>sem</code> - <strong>0xdddddddddddddddd</strong> - This is always the same, on every crash.</li>
  <li><code>lock_acquired</code> - <strong>false</strong>. </li>
  <li><code>old_count</code> - <strong>0xdddddddddddddddd</strong>. </li>
  <li><code>this</code> - Appears to be valid, and the address of it matches what the object holding it has (the object of which <code>handle_write</code> is a method). It does not appear to have been deleted or messed with in any way.</li>
  <li><code>this-&gt;active_count</code> - A negative integer, ranges I've seen have been between -570000000 and -580000000.</li>
  <li><code>this-&gt;event</code> - <strong>0xdddddddddddddddd</strong>. </li>
  </ul></li>
  </ul>
  
  <p>I am unfortunately unable to see the result of the <code>WaitForSingleObject</code> call.  The <a href="http://msdn.microsoft.com/en-us/library/ms687032%28VS.85%29.aspx" rel="nofollow">MSDN entry</a> on the API function indicates four possible return types, two of them impossible in this scenario. Since <code>WaitForSingleObject</code> is being called with an invalid event handle (<code>sem</code> = <code>0xdddddddddddddddd</code>), I assume it's returning <code>0xFFFFFFFF</code> and GetLastError would indicate that an invalid handle has been supplied.</p>
  
  <p>So the actual problem, it seems, is that the <code>get_event()</code> method of <code>basic_timed_mutex</code> is returning <code>0xdddddddddddddddd</code>. However, the <a href="http://msdn.microsoft.com/en-us/library/aa915030.aspx" rel="nofollow">MSDN entry</a> for <code>CreateEvent</code> (which <code>get_event()</code> eventually uses) tells me that it returns either a valid handle to an event, or <code>NULL</code>. </p>
  
  <p>Again, this is probably the best description of the problem I can provide since it isn't reproducible reliably outside of this specific application. I hope somebody has ideas as to what may be causing this!</p>