[fpc-devel] threads vs widestringmanager / crash

[Ondrej Pokorny]

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