bughunting weirdness and other stuff

[revelator]

New version is quite ingenious but there were a few things that needed checking.
mutex locks opening the same mutex in two places with CreateMutex is a recipee for disaster because the second lock would get ERROR_ALLREADY_EXIST and wont be given permission to lock the cleanup function. So use OpenMutex to check if the lock is still active
and if that is the case use that else recreate it with CreateMutex.

Sadly there are more examples of things that break with the mutex locking mechanism, for one glib2 started using mutex locks as well and the version they use deadlocks the TDM mutex causing more or less the same exception to be thrown as the example above.

Took me quite a while but here is a version of the shmem mechanism that is pretty reliable ->
0160-shared-memory.zip

it still borks at the glib2 mutex at times so i made an extra flag to be used in CFLAGS / CXXFLAGS -> _USE_SHMEM to turn the shared pointer code on or off in your project, downside is that anything compiled without setting -D_USE_SHMEM=1 will not be able to throw exceptions across dll boundaries but normal exceptions still work. This is a workaround untill we can figure out a way to protect the mutex functions from being tampered with by external sources.

[jmeubank]

CreateMutex on a named mutex that already exists, returns a handle to the existing mutex. Can you provide a sample where you proved that this didn't happen? (I.e. proves Microsoft's documentation about mutex behavior to be wrong.) Otherwise you're simply wasting effort with this. Named mutexes cannot deadlock other mutexes, only themselves (i.e. the mutex with that unique name). Get Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: Ralph Engels ***@***.***> Sent: Friday, October 7, 2022 6:50:57 AM To: jmeubank/tdm-gcc ***@***.***> Cc: Subscribed ***@***.***> Subject: [jmeubank/tdm-gcc] bughunting weirdness and other stuff (Discussion #60) New version is quite ingenious but there were a few things that needed checking. mutex locks opening the same mutex in two places with CreateMutex is a recipee for disaster because the second lock would get ERROR_ALLREADY_EXIST and wont be given permission to lock the cleanup function. So use OpenMutex to check if the lock is still active and if that is the case use that else recreate it with CreateMutex. Sadly there are more examples of things that break with the mutex locking mechanism, for one glib2 started using mutex locks as well and the version they use deadlocks the TDM mutex causing more or less the same exception to be thrown as the example above. Took me quite a while but here is a version of the shmem mechanism that is pretty reliable -> 0160-shared-memory.zip<https://github.com/jmeubank/tdm-gcc/files/9734423/0160-shared-memory.zip> it still borks at the glib2 mutex at times so i made an extra flag to be used in CFLAGS / CXXFLAGS -> _USE_SHMEM to turn the shared pointer code on or off in your project, downside is that anything compiled without setting -D_USE_SHMEM=1 will not be able to throw exceptions across dll boundaries but normal exceptions still work. This is a workaround untill we can figure out a way to get protect the mutex functions from being tampered with by external sources. — Reply to this email directly, view it on GitHub<#60>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKSVUFGAFKBY4PEFZFOPKA3WCATEDANCNFSM6AAAAAAQ7TUVZA>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[revelator]

lldb output ->

Process 23384 launched: 'I:\Msys2\tdm32\bin\gdk-pixbuf-query-loaders.exe' (i386)
Process 23384 stopped
* thread #1, stop reason = Exception 0xc0000005 encountered at address 0x6244a566: Access violation reading location 0x707730a4
    frame #0: 0x6244a566 libyuv.dll`CanonicalFourCC + 52166
libyuv.dll`CanonicalFourCC:
->  0x6244a566 <+52166>: movl   0x4(%eax), %eax
    0x6244a569 <+52169>: testl  %eax, %eax
    0x6244a56b <+52171>: jne    0x6244a558                ; <+52152>
    0x6244a56d <+52173>: cmpl   $0x624580a0, %edx         ; imm = 0x624580A0

[revelator]

btw i was not trying to stop the mutex from doing what it was supposed to, i was trying to avoid anything else from accessing it when it was doing it. Ok got the original version bootstrapped but i also have to rebuild the dependencies of gdk-pixbuf2 which will probably take a while since the Msys2 project has grown into a monster of circular dependencies xD. All my work was actually to get it accepted as a plugin for the Msys2 shell since most gcc devs on windows use that atm (well except the hardcore users who prefer doing it from wsl).

[revelator]

Oo omg. i just discovered the source of the segfault and you are going to laugh now (or maybe cry i was not sure either) it is caused by
this -> if ( WaitForSingleObject( yada, yada, yada) == waitforit) drumrool.... if i change the "if" to "while" it works even with the old version what the actuall hell....

[revelator]

seems a bug to me but using "while" actually works i created a small test program using the code from your version only with the atomic counter i used in mine as an extra guard (does not hurt anything).

mutex lock1 signaled: check error walue (null)
mutex lock1 running: count was: (00000001): check error walue (null)
mutex lock2 signaled: check error walue (null)
mutex lock2 running: count was: (00000001): check error walue (null)

this is the output, i use a small Sleep timer to simulate running code after we get the lock.

so it does what it is supposed to now it seems, the error null just means there are no errors returned from GetLastError.
attaching the source and test executable it is actually pretty helpfull to muck around with it, try for instance to change the "while" to "if" again and build it with debugging on.

I remove the acl code, though it works with that also, so feel free to use it (was actully from a microsoft dev in regards to getting full access to a mutex object on win10).

[revelator]

test-mutex-src.zip

here is the test program and source, does work in bash also but you need to press ctrl+C to see the output if run directly it shows instantly.

[revelator]

Debug build of gcc-10.4.0 with the TDM patchset uploaded here -> https://sourceforge.net/projects/cbadvanced/files/TDM%20Debug/

built with -ggdb3 to get as much debug info as possible, changed the if before WaitForSIngleObject to while, all static dependencies used.
built with binutils-2.39 but since the 32 bit build is sjlj it should not matter, if it had been a dwarf build it would be required though due to the new dwarf 5 format, the 64 bit build is SEH.

[revelator]

turns out the mutex lock was not working at all in either function, lots of debugging later and i now have a working gcc-11.3.0-tdm :) with full ASLR and DEP support, could not get ASLR working previously in TDM turned out it was the mutex lock that keeled us over.

so far i managed to build 50% of the MSYS2 mingw packages with it (damn thing has grown to a monster xD) so it will be a while but i can upload the packages when done. Ill also include replacement packages for MSYS2's filesystem and pacman to add the TDM compiler to the toolchain.

@jmeubank feel free to use my patch and PKGBUILD when it is up.
btw. in case you were wondering im RalphE so not the first time i done some work for the stability of this toolchain. i retired from the coding scene some years back though so im a bit rusty.

[revelator]

graphviz built by TDM with QT5

[revelator]

https://sourceforge.net/projects/cbadvanced/files/TDM%20Release%20ASLR/

compiler and binutils no external dependencies.

still building a frag ton of MSYS2 mingw-w64 packages with this which will be uploaded later. there is a chance that this package might make it into the MSYS2 release if approved.