On Monday 17 February 2025 13:13:29 Martin Storsjö wrote: > On Thu, 13 Feb 2025, Pali Rohár wrote: > > > On Thursday 13 February 2025 14:16:06 Martin Storsjö wrote: > > > On Fri, 7 Feb 2025, Pali Rohár wrote: > > > > > > > This will report runtime error if _CRT_INIT(DLL_PROCESS_DETACH) is > > > > called > > > > by the current thread from some atexit_table hook. > > > > > > Btw, I forgot to ask; how would one practically do in order to trigger > > > this > > > case? I know it's a kinda pathological case that one ideally wouldn't ever > > > hit, but I wonder if you even know of a theoretical case. I guess one case > > > is an atexit function which explicitly references the _CRT_INIT symbol? Or > > > if an atexit function tries to FreeLibrary() on the same DLL that it > > > belongs > > > to, or something like that? Something else? > > > > > > // Martin > > > > It is edge case and I have just imitated logic which is doing visual c++ > > startup/shutdown code. > > > > I thought that this code can catch stupid/basic issues related to single > > threaded application when some startup or shutdown hook would call > > _CRT_INIT() function with DLL_PROCESS_DETACH or DLL_PROCESS_ATTACH. > > But not, after reading your comment and looking at the code again, > > now I see that this guard does: > > - NOT detect _CRT_INIT(DLL_PROCESS_DETACH) call from startup hook > > - NOT detect _CRT_INIT(DLL_PROCESS_DETACH) call from atexit hook > > > > What it can theoretically detect is that during FreeLibrary() call when > > _CRT_INIT(DLL_PROCESS_DETACH) is being executed, some other running > > thread executes _CRT_INIT(DLL_PROCESS_DETACH) in parallel. > > In this case while loop with InterlockedCompareExchangePointer would > > wait in Sleep(1000) until the other thread release __native_startup_lock > > and then would call _amsg_exit(31) because __native_startup_state would > > not be __initialized anymore. > > Right - so even if this patch doesn't do what you originally described it to > do, we should still go ahead with it?
msvc startup files are doing also this thing. So I would suggest to go ahead with this change, unless there is a reason why not to follow msvc. > I.e. we should tweak the commit messages and still consider it for merging? > > Feel free to suggest updates to the commit messages that need to be updated > after this realization. What about this commit message? crt: Guard nested _CRT_INIT(DLL_PROCESS_DETACH) call for DLL builds It is questionable which real issue can this guard detect or prevent, but dll detach code from Visual C++ runtime is doing same thing. And it makes sense that mingw-w64 would have compatible dll detach logic with the Visual C++ dll detach code. > Btw, I'll be away on vacation for 9 days from now/soon, so I might not be > able to respond to issues here in a little while. _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
