Re: [fpc-devel] threads vs widestringmanager / crash
Ondrej Pokorny via fpc-devel 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
Re: [fpc-devel] threads vs widestringmanager / crash
On Mon, 19 Dec 2022, Ondrej Pokorny via fpc-devel wrote: On 19.12.2022 09:51, Michael Van Canneyt via fpc-devel wrote: If you can prepare a simple sample program that shows the problem, I can try to look into it. Maybe a fresh pair of eyes sees more than one pair of eyes? You don't need a special sample program. Every console application on Windows will do. Just run it with debugging in Lazarus. Ah, Windows. I have no working installation available for it. That will take time to set up :/ The fact that it shows up when execution is slow is strange. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] threads vs widestringmanager / crash
On 19.12.2022 09:51, Michael Van Canneyt via fpc-devel wrote: If you can prepare a simple sample program that shows the problem, I can try to look into it. Maybe a fresh pair of eyes sees more than one pair of eyes? You don't need a special sample program. Every console application on Windows will do. Just run it with debugging in Lazarus. My observation is that the problem is worse on slow machines (virtual machines, shared VPS). I actually almost never observed it on my local PC, but on the VPS it made debugging nearly impossible. I'll disable the "Assigned(WideStringManager.GetStandardCodePageProc)" hack on the VPS and report back. Ondrej ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] threads vs widestringmanager / crash
On Mon, 19 Dec 2022, Ondrej Pokorny via fpc-devel wrote: 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.) I think the assumption is definitely correct: some subsystems needs to be initialized. Since there are multiple systems to initialize, there will always be moments in code where one system is initialized and the other is not All code should be prepared to deal with that. This counts double for systems where initialization is delegated to other units: strings/threads on unix, for example If you can prepare a simple sample program that shows the problem, I can try to look into it. Maybe a fresh pair of eyes sees more than one pair of eyes? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
