2018. 03. 09. 12:09 keltezéssel, Tony Whyman via Lazarus írta:
Finally, knowing all this, I go back to Gabor's program and add the line
(again shown in context):
repeat
SQR:=SM.Query(nil,SRB);
for i:=0 to SQR.GetCount-1 do
begin
case SQR[i].getItemType of
A supplementary for anyone confused by the last extra parameter to
SetString in the previous post (repeated below). When I wrote up the bug
report, I should have gone one step lower in the code. The SetString
commented out below is actually an internal function:
procedure
Thanks to Giuliano mentioning debug libraries I have been able to
duplicate the problem and to find the source of the bug - but it is as
weird as it gets.
FYI: tests done on Linux Mint 18 with Lazarus 1.8.0 and fpc 3.0.4.
The evidence so far:
1. Gabor's program ends with an exception when
Giulian,
You may in a roundabout way have pointed me at where the problem lies. I
always work with fpc debug libraries as well and I can't catch the
problem. I changed to the standard release and the bug appears!
Unfortunately, while duplicating the problem is one thing, tracking it
down
Il 09/03/2018 10:14, Gabor Boros via Lazarus ha scritto:
Any idea how to detect what/where is the source of the exception?
I use Linux 64bit, FPC 3.0.4 and Lazarus fixes_1_8.
To obtain meaningful information from gdb I do the following:
1) Compile both Lazarus LCL and fpc with debug info
2)
Gabor,
I can't duplicate your problem which probably implies that we are
looking at some weird race condition during the program tidy up phase. I
did see occasionally something like this before with Lazarus 1.6.4 on
Windows with heaptrc - but I never saw it without heaptrc and it cleared
up
Hi All,
The result of the attached example (which use MWA's Firebird Pascal API)
for me is an exception:
Gstat execution time Fri Mar 9 09:29:18 2018
Database header page information:
Flags 0
Generation 173
System Change Number0
