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

Reply via email to