strange bug with WaitForSingleObject

[revelator]

Been trying to solve a bug for some time then by mistake while writing a new test i changed the "if" to a "while" before a call to WaitForSingleObject and it worked ?!?.

the problem was that i was doing a mutex lock by means of "if (WaitForSingleObject(handle, INFINITE) != WAIT_OBJECT_0) go bye bye"
but this caused a segmentation fault even though it should be perfectly legal, my fault and what actually turned out to work was changing it to while(WaitForSingleObject(handle, INFINITE) != WAIT_OBJECT_0) go bye bye. is this a bug somewhere in the mingw-w64 api ?.

[Biswa96]

Would you like to provide any minimal sample code? mingw-w64 does not implement any Win32 APIs. It only declares those.

[revelator]

sure it is just a simple test but try changing the "while" in it to "if" and see what happens :) strangely this only occurs with the 32 bit api.

#if !defined(WIN32_LEAN_AND_MEAN)
# define WIN32_LEAN_AND_MEAN
# include <windows.h>        /* handles and other windows types */
# include <stdlib.h>         /* For _onexit */
# include <stdio.h>          /* For printf */
#endif

#define VALID_HANDLE( status ) ( ( HANDLE )( status ) > NULL )
#define mutex_name "oh_hell"

int main(void)
{
  /* the counter makes sure nothing tries to create a new mutex untill we released the old one.
   * if counter == 0 we can create a new one which in turn increments the counter to 1, 
   * so we decrement the counter after a successfull release of the mutex to allow a new one to be created.
   */
  SECURITY_ATTRIBUTES SecurityAttributes;
  SECURITY_DESCRIPTOR SecurityDescriptor;

  /* set security to NULL so everyone can read/write our memory file */
  InitializeSecurityDescriptor( &SecurityDescriptor, SECURITY_DESCRIPTOR_REVISION );

  SetSecurityDescriptorDacl( &SecurityDescriptor, // address of security descriptor
                              TRUE,               // flag for presence of discretionary ACL
                              NULL,               // discretionary ACL of NULL gives everyone access
                              FALSE               // flag for default discretionary ACL
  );

  SecurityAttributes.nLength = sizeof( SECURITY_ATTRIBUTES );
  SecurityAttributes.lpSecurityDescriptor = ( LPVOID )&SecurityDescriptor;
  SecurityAttributes.bInheritHandle = FALSE;

  /* horsie was dead on arrival buy another. */
  HANDLE m_mutex = CreateMutexA( &SecurityAttributes, FALSE, mutex_name );
  size_t m_count = 0;

  do
  {
    /* if we got the mutex and the mutex handle did not allready exist break out else abort */
    if ( VALID_HANDLE( m_mutex ) )
      {
        /* mutex successfully created increment by 1 and lock it down. */
        m_count += 1;
        break;
      }

    /* crap... */
    abort();
  } while( m_count < 1 );

  /* using an if here segfaults */
  while ( WaitForSingleObject( m_mutex, INFINITE ) == WAIT_OBJECT_0 || WAIT_ABANDONED )
  {
    /* count should be 1 here if it is not bad things happened */
    printf( "mutex lock1 signaled count was: (%p): possible error was %s\n", m_count, GetLastError() );
    break;
  }

  do
  {
    /* release the poor overworked horsie. */
    if ( ReleaseMutex( m_mutex ) != 0 )
      {
        /* decrement by 1 on success so that we can load a new one. */
        m_count -= 1;
      }

      /* cannot kill dead or non existing horsies anyway so bah... */
      CloseHandle( m_mutex );
  } while( m_count > 0 );

  return EXIT_SUCCESS;
} 

[revelator]

when it runs the error return should be null and the count should be 1 (been running for ours now with no error) when changing the "while" to an "if" it segfaults immediatly :S

[revelator]

also tried CreateMutexA( NULL, FALSE, mutex_name ); and same problem so it seems to be some odd behavious from WaitForSingleObject.
Might also affect WaitForMultipleObjects if that is so. optimized the test source a bit for more consistent output though in bash you have to press ctrl+c to see the output, running it directly shows the result instantly.

[revelator]

well as it turns out both ways can be made to segfault on what appears to be valid code though it is extremely easy using "if".
whole mess is just really fragile and one needs to take great care with conditionals it seems.

[revelator]

well seems this has only recently become a problem, but more and more bug reports are turning up now with this function crashing on otherwise working code.