On 20.12.2022 21:12, Sven Barth via fpc-devel wrote:
Please stop focusing on the WideString manager. That is simply a
symptom. The real cause is that a thread is created where there
shouldn't be one and under normal circumstance there indeed will be none:
- if the initialization is executed as part of an application then
there won't be any other thread, because the system initialization
doesn't create one
- if the initialization is executed as part of a library then there
won't be any other thread, because the initialization is run during
the DLL_PROCESS_ATTACH call of the entry point which Windows executes
with the global loader lock held, thus no thread can enter the entry
point (which is also why there are some things you shouldn't do in a
unit initialization)
The only cause for a thread to exist at that point is if another
process calls CreateRemoteThread(Ex)() to create a thread in the
process that is just initializing (Note: DebugBreakProcess()
internally uses CreateRemoteThread(Ex)()). This means that the thread
can interfere at *any* point of the initialization simply depending on
the behavior of the Windows scheduler (as you hinted at in your other
mail from today).
So the only logical solution is to stop the offending thread from
executing or not to have it call InitThread() while the initialization
section of the System unit is still running. The former might have
unintended consequences (e.g. not being able to debug the unit
initialization) while the later might work in most cases as long as
that remote thread doesn't need to execute code that relies on
InitThread().
Sven, thank you very much for the insights!
I would much appreciate a solution without my hacks.
Ondrej
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
