On Wed, 11 Nov 2020, Jeremy Drake wrote: > On Wed, 11 Nov 2020, Martin Storsjö wrote: > > > Pushed patches 1-2 for now (that should be very benign and safe in any > > case); patch 3 (changing how winpthreads clean up threads) is a bit more > > risky, and the conclusion of this discussion was a bit fuzzy, but I can > > push that one as well if others (Jeremy?) wants it in. > > > > // Martin > > Unfortunately, the winpthreads patch was not sufficient in the case of a > dynamic winpthreads (which seems to be default in the mingw toolchains in > msys2, at least): with or without the patch, emutls was still being freed > prior to the destructors running. I saw this as occasional garbled log > messages in your test cases.
Have there been any further ideas on this? I am concerned the current state of affairs, accessing freed memory during tls destruction of objects in the .exe module, could cause crashes in objects more complicated than simple logging test cases. The proposed "patch 3" dealt with this when statically linked with winpthreads, but Windows called winpthreads.dll's callbacks before those from the main .exe module. _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
