[fpc-devel] threads vs widestringmanager / crash

[Sven Barth]

Ondrej Pokorny via fpc-devel <fpc-devel at lists.freepascal.org> schrieb am
Mo., 19. Dez. 2022, 08:30:

> On 19.12.2022 07:42, Sven Barth via fpc-devel wrote:
> > The RTL assumes that it does not have to deal with threads during the
> > initialization of the System unit. So even if the symptom of the crash
> > is fixed in that location it isn't said that something else might
> > crash or that in the future code might be added that crashes...
>
> Is it possible to acknowledge that the current RTLs assumption is wrong
> and it has to deal with threads during the System initialization?
> (Because obviously the assumption is wrong, otherwise there was no crash.)
>

The RTL needs to make some assumptions, because it is the one that sets up
the synchronization primitives and under normal circumstances this
assumption *is* true. As you mentioned in the other mail the crash depends
upon execution speed and thus it could very well happen during
initialization of the heap as well.


> That means not to fix the symptom with checking
> "Assigned(WideStringManager.GetStandardCodePageProc)" but acknowledge
> that the OS can start a thread before System initialization is done and
> create a mechanism to postpone thread initialization until System is
> fully initialized.
>
> Something like:
>
>      procedure InitThread(stklen:SizeUInt);
>        begin
> // new code begin
>          while not SystemInitialized do
>            Sleep(10);
> // new code end
> {$ifndef FPUNONE}
>          SysResetFPU;
> {$endif}
>

It will probably come to something like this.

Though we should first check what it means for the user if the debugger
thread is hold in place.

Regards,
Sven

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20221220/77db4098/attachment.htm>