anyone good at mutex locks ?

[revelator]

been having a really bad time trying to fix a goofup with the TDM based gcc compiler.

the older code used one named mutex for locking which mostly worked (hard to check mutexes) the new version uses two functions which requires the code to be locked down but the TDM dev made the mistake of using CreateMutex in both functions as the default causing a rather nasty bug because the named mutex object allready existed so the second mutex lock ended up getting ERROR_ALLREADY_EXIST OR ACCESS_DENIED on the mutex lock.

So i changed it to use OpenMutex with the SYNCHRONIZE flag checking if the named mutex allready existed and if that was not the case then we could try with CreateMutex.
 

  /* This mutex is needed to prevent another __eh_shmem region being added or removed in the time between
   * the FindAtomA call and when we finish traversing the linked list and adding ourselves to the end of
   * it. The named mutex may allready exist if so we use it, else we need to create it again.
   */
  HANDLE access = OpenMutexA( SYNCHRONIZE, FALSE, mutex_name );

  do
    {
      /* aw no not dead again... */
      if ( !VALID_HANDLE( access ) )
        {
          /* try to recreate the mutex handle */
          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;

          /* a unicorn!!! */
          access = CreateMutexA( &SecurityAttributes, FALSE, mutex_name );

          /* if a valid handle break out, else return EXIT_FAILURE */
          if ( VALID_HANDLE( access ) )
            {
              break;
            }
          return EXIT_FAILURE;
        }
    } while( 0 );

  /* try to lock the code below */
  if ( WaitForSingleObject( access, INFINITE ) != WAIT_OBJECT_0 )
    {
      /* horsie was a mule... */
      CloseHandle( access );
      return EXIT_FAILURE;
    }

 

The security stuff is because a Mutex may not have all access unless run as admin so we force it :).

the main function also checks if the mutex is allready active -> yep this one ERROR_ALREADY_EXISTS and in that case just exits early.

it runs a lot better now than it used to but a few sources still give me some grief like gdk-pixbuf2 which segfaults on some loaders (only happens with the TDM compiler and not all loaders crash which is strange as hell).

SO if someone could help me getting to the button of this id be gratefull.

[revelator]

0160-shared-memory.zip0160-shared-memory.zip

the complete patch for shared pointers support in TDM if you need a better view of what is going on. The code is rather large so better to just send the patch instead of posting a huge block of text here.

 

if you want to test it yourself use gcc-10.4.0 as that was the version this patch was made against, might also work with gcc-10.3.0.

[OrbWeaver]

I don't even understand what this code is about.

What is the "TDM based GCC compiler"? The TDM team doesn't write C compilers, does it? Why would we need to deal with such low-level mutex and shared memory code?

[revelator]

hehe yeah the name is a bit confusing TDM != the dark mod but i forgot that xD.

the TDM based gcc compiler is a version of gcc that supports throwing exceptions across dll boundaries without linking to the shared gcc runtimes, it was originally based on a very old patch from mingw.org back when mingw gcc could not even build the shared runtimes so exceptions were broken without it. Later it was picked up by another dev who used it to create a version of gcc for those who did not want the gcc runtime dll's as dependencies of every windows program they created. Over the years some bugs crept up with newer version of gcc and he updated his code to support those but unfortunatly he was even worse at mutex locks than me xD so the new version caused numerous bugs. I been trying for some time to get it corrected so that it would be in a useable state again.

 

i was just hoping that maybe someone here could maybe spot more goofups so i can get them fixed before it makes it way into the msys2 packages.

[revelator]

so far out of the hundreds of packages currently supported by msys2 mingw-w64 it builds about 99% and about 97% of them work, current offenders are gdk-pixbuf2 (or maybe one or more of the libraries the loader code links against) ogre3d (sometimes works strangely ?!?) and ofc gimp or any other gtk based package that relies on the gdk-pixbuf2 loaders. Strangely gtk2 gtk3 and gtk4 all work fine so im a bit stumped by this.

[OrbWeaver]

I'm afraid you may be on your own with this one.

Using dodgy unofficial compiler patches to hack in a new way of passing exceptions between DLLs (which is generally risky and prone to silent failure even when using a sane compiler setup), and then using this to target a very non-standard platform/package combination (GTK on MSYS/Windows), sounds like such a horrific maintenance nightmare that I wouldn't personally touch it with a ten foot pole.

[revelator]

not exactly unofficial as said it was used for years doing the grunt work with the now defunct mingw.org compiler (and cygwin) and it worked pretty well back when we could not even build the dll's on windows. Ofc the complexity of gcc has multiplied since those day's so it had to be updated to reflect that. Debugging atleast told me it was crashing in the mutex locking mechanism, so after a whole lot of reading about mutexes in general i went to work and it is quite stable now except with those few sources. That said i might be in over my head from here on because the debugger tells me those are crashing in ntdll.dll but not what it is that is crashing them :S i only get a stack trace.

the most funny thing and something which was not done originally is that the shared pointers code only runs when linked to the static runtimes it does not run when linked to the shared runtimes so should not affect things built using that, but even that does not work for said sources... crashes with the exact same error so it might not even be where i think it is.

[revelator]

the  original did not even use mutex locks instead it used the CTOR DTOR mechanism from the crt to decide when to run it, was also a whole lot messier to read and the code for enabling it for the C++ exception handler was rather crude (only supported throwing abort on error) incidently both the terminate_handler and unexpected_handler of this shared the same code which funny enough gcc reverted to with the latest version since c++17 does not support unexpected at all.

[revelator]

well seems my latest iteration of the patch managed to fix the buggers i had with gdk-pixbuf2 and ogre they now work just fine looks like parsing the acl's and setting permissions accordingly on the mutex was all that was needed, only seems to be a problem if using win10 so something tells me that they started getting serious about security features in the windows api.

[revelator]

forgot one thing in WaitForSingleObject you can not use an "if" to get the wait value doing so causes a segfault instead use a "while" or use a case switch, had to create a test program to try out the functions and it repeatedly segfaulted untill i did that change. works better than ever now older versions of the patch only used one such mutex lock instead of two and mostly worked but sometimes it caused some oddities which it seems was because the mutex lock newer worked to begin with.

[revelator]

turned out the broken mutex locking mechanism was also the culprit causing TDM-GCC to not be able to use ASLR i now have a fully ASLR and DEP compatible build of it.

yes the image below is graphviz built by my TDM compiler and yes it (and all dependencies) use adress space layout randomization. Still a ways to go rebuilding all the packages from MSYS2 but slowly getting there.

 

MSYS2 has tons of libraries and tools geared toward anything you can imagine (several game related),

for one it has a full build of the godot engine, ogre3d, irrlicht, openscenegraph, blender (only 64 bit), and all the imaging libraries you can imagine. Also a vulkan loader glslang and hlslang compiler.

[revelator]

godot game engine demo