So it gets stranger, the first time I ran that today the GPF in my app fully crashed Lazarus itself. Each crash since has showed the fault exactly as per Lazarus 3.6 and not crashed the IDE. The other day when I initially reported this, was happening every time.
That could indicate that the error is either
- a race condition (sensitive to very very small changes in timing)
However, given that it used to happen 100%, that doesn't fit completely
- an uninitialized/dangling pointer access (including bugs in the compiler)
A race condition would mean, that the order in which the IDE receives the events from the debugged process, and other events from the outside (such as paint, mouse, keyboard) matters, and that if 2 specific of those events occur exactly in the right order, with the exact correct time between them (usually micro seconds), then and only then it fails.
But, race conditions rarely happen 100% of the time over a long time, and then stop or become less frequent.
(Except, if some other part of the fault changes / a race condition could trigger a dangling pointer... and that may change)
That said, there is some thread-shared data in the exact code where you recorded the crash. And data shared between threads is often the base for race conditions.
I am sure, I did review that when I wrote it, and again later (there was a dangling pointer issue some years back, that was near impossible to find, and at that time I reviewed all thread shared data). Yet, I have put it on my list to review it again (but for that I need to make some more time).
A dangling pointer could be.
You did rebuild the IDE (and with different setting, e.g. -O-1 ). Any setting change would change the exact memory layout (some asm code may be differently optimized, and change in size / some data may be differently aligned, other optimizations can touch mem layout of the data).
In other words, the IDE still works with the same data, but the order in which variables are placed into the RAM of your PC may have changed.
An uninitialized/dangling pointer means that some random data gets damaged at some point (and later triggers the crash). If that was the case, then the "random data" may now be either not causing a crash, or it may be within free/unused memory.
That is something that valgrind can pick up (even if no crash happens).
You are using FPC 3.2.2 ?
I remember there was at least one (I think I saw even 2 different reports) where that FPC would wrongly translate valid Pascal code, so that the result would have a dangling pointer. (even that was not in the original Pascal code).
One of those was only found on Windows (it is possible it could happen on other OS, but it was never observed despite a real in depth search).
IIRC both of those are in the optimizer.
So you could try to build your IDE with -O-Mind you, both of them are about as likely as winning a significant bit in the lottery.
So its probably not them. But ....
You can also build your IDE alternating with
-O2
-O-1
-O-
and see if the crash appears/disappears.
If that makes a diff, it could still be a bug in the debugger code, rather than the compiler. Both would be possible.
You could then next try to get the 3.2.4RC and test with that. (or use fpcupdeluxe to install 3.2.3 / fixes_3_2 => fpcupdeluxe makes it easier to have 2 installs)
Recent
