Ondrej Pokorny via fpc-devel <fpc-devel@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
>
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
