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? 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.
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.
// Martin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
