On 21/12/2022 11:37, Marc Weustink via fpc-devel wrote:
On 20-12-2022 21:12, Sven Barth via fpc-devel wrote:
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. Th
On 20-12-2022 21:12, Sven Barth via fpc-devel wrote:
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 b
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 p
Am 20.12.2022 um 15:08 schrieb Martin:
Ok, I don't know too much about the whole initialization
But on the off chance of triggering some ideas, I throw in a couple of
my thoughts
On 19/12/2022 07:42, Sven Barth wrote:
Am 07.07.2018 um 15:04 schrieb Martin:
So (guessing) the original i
Ok, I don't know too much about the whole initialization
But on the off chance of triggering some ideas, I throw in a couple of
my thoughts
On 19/12/2022 07:42, Sven Barth wrote:
Am 07.07.2018 um 15:04 schrieb Martin:
So (guessing) the original issue may be due to the debugger. The
de
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 locat
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 s
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 w
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
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 mi
Am 07.07.2018 um 15:04 schrieb Martin:
So (guessing) the original issue may be due to the debugger. The
debugger interrupts the target early on. And that does create a thread
in the target.
If such an external thread happens, would fcp execute the code in
question?
This is likely to be the ca
I have the same problem. It is very annoying because programs crash
quite often when run in a debugger (on Windows).
I solved it with the attached patch - I added these lines to procedure
OpenStdIO(var f:text;mode:longint;hdl:thandle);
{$if defined(FPC_HAS_CPSTRING) and defined(FPC_HAS_FEAT
Ok, I guess the "TThread.Queue" is wrong.
Because that may create an instance, but there would not actually be a
2nd thread as observed. (Question 1 is still interesting)
Yet there is no other TThread.Create call made.
So (guessing) the original issue may be due to the debugger. The
debugger
There actually isnt a thread started.
But during initialization "TThread.Queue" is called (because the code in
question can be called in threads aswell, and must ensure work is done
in the main thread)
"TThread.Queue" creates a new external thread. This fails during unit
initialization for t
14 matches
Mail list logo