[SOLVED]LazReport crashes sometimes with Windows 11

[Guylain]

I'm using Lazarus 2.0.0 r60307 on Windows 11.
I develop a software creating reports from DBF data of an accounting software.
My program uses LazReport to display DBF data, sent to report from a StringGrid to a frUserDataset.
After loading data from DBF file without an itch, the view to report begins to process page 1 and after few seconds quit the program without notice.

To be sure, I tried the same program on another PC with Windows 10, and everything is ok.


Any idea?

[balazsszekely]

I'm using Lazarus 2.0.0 r60307 on Windows 11.
I develop a software creating reports from DBF data of an accounting software.
My program uses LazReport to display DBF data, sent to report from a StringGrid to a frUserDataset.
After loading data from DBF file without an itch, the view to report begins to process page 1 and after few seconds quit the program without notice.

To be sure, I tried the same program on another PC with Windows 10, and everything is ok.

And something weird: I keep backups of the program about each day, and i can run a version created about a month ago without problem on Windows 11. So, I change something in the report Windows 11 doesn't like.

Any idea?

Unfortunately there is not enough information to work with. Create a backtrace, maybe it helps:
https://wiki.freepascal.org/Creating_a_Backtrace_with_GDB

[Guylain]

Thanks for the quick reply.
When I disable the Two-pass report option, I get the 'External: SIGSEGV' error.
Here is the backtrace (I' afraid there is not much infos there):

#0 ntdll!RtlVirtualUnwind2 at :0
#1 ?? at :0
#2 ?? at :0
#3 ?? at :0
#4 ?? at :0
#5 ?? at :0
#6 ?? at :0
#7 ?? at :0
#8 $unwind$VARUTILS_$$_WSTRTODOUBLE$POINTER$$DOUBLE at :0
#9 ?? at :0
#10 ?? at :0
#11 ?? at :0
#12 ?? at :0
#13 ?? at :0

[balazsszekely]

Here is the backtrace (I' afraid there is not much infos there):

No, not much. Do you convert string to double in your report?

[Guylain]

No, I use variables directly in memos, like this:

In code:

Code: Pascal  [Select][+][-]

1. Case ParName of
2.    'TauxCNESST'  ParValue := SG_Data.Cells[ 33,FRow];

In LazReport:

Code: Pascal  [Select][+][-]

1. [100*[TauxCNESST]] $/100h

Some values from database have 12 digits and some have 3, 4 or five decimals

After some debugging step by step, i found LazReport crashes on some memos scripts , like date with a format like "19 septembre 2015' (I'm french-canadian).

I changed the format for 'Text' for all Memos with date. Now LazReport stops a little bit farther, at memo 49, which seems quite usual:

Code: Pascal  [Select][+][-]

1. [IF([VacAnn]<>0, [VacAnn], 'non-spécifié')]

VacAnn is a integer positive value coming as a string from my TfrUserDataSet

If I erase the content of memo, I can step to next memo.

Precisely, the crash happens in the unit 'LR_Class' of LazReport, at the highlighted line 17:

Code: Pascal  [Select][+][-]

1. procedure TfrBand.DrawObject(t: TfrView);
2. var
3.   ox,oy: Integer;
4. begin
5.   {$IFDEF DebugLR}
6.   DebugLnEnter('TfrBand.DrawObject INI y=%d t=%s Xadj=%d Margin=%d DiableDrawing=%s',
7.   [y,ViewInfoDIM(t),Parent.XAdjust,Parent.LeftMargin,BoolToStr(DisableDrawing,true)]);
8.   {$ENDIF}
9.   CurPage := Parent;
10.   CurBand := Self;
11.   AggrBand := Self;
12.   try
13.     if (t.Parent = Self) and not DisableDrawing then
14.     begin
15.       ox := t.x; Inc(t.x, Parent.XAdjust - Parent.LeftMargin);
16.       oy := t.y; Inc(t.y, y);
17.       t.Print(MasterReport.EMFPages[PageNo]^.Stream);
18.       t.x := ox; t.y := oy;
19.       if (t is TfrMemoView) and
20.          (TfrMemoView(t).DrawMode in [drAll, drAfterCalcHeight]) then
21.         Parent.AfterPrint;
22.     end;
23.   except
24.     on E:Exception do
25.       DoError(E.Message);
26.   end;
27.   {$IFDEF DebugLR}
28.   DebugLnExit('TfrBand.DrawObject DONE t=%s:%s',[dbgsname(t),t.name]);
29.   {$ENDIF}
30. end;

[Edited to add code tags; please read How to use the Forums.]

[Guylain]

I have more precise infos about the crash.

With GDB, I found the error occurs in the LR_Pars unit, at TfrParser.CalcOPZ function, at line 175.

nm variable is an array of variants. With assembler window, i see the crash is about the conversion from variant to a formal type.

It's only happening for the "ttNe" operator (non equal). Others memos with formulas preceding this one are OK;

Code: Pascal  [Select][+][-]

1. function TfrParser.CalcOPZ(const s: String): Variant;
2. var
3.   i, j, k, i1, st, ci, cn, l: Integer;
4.   s1, s2, s3, s4: String;
5.   nm: Array[1..32] of Variant;
6.   v: Double;
7.   vCalc: Variant;
8.   vBool: boolean;
9. begin
10.   {$IFDEF DebugLRCalcs}
11.   DebugLnEnter('TfrParser.CalcOPZ INIT s=%s',[dbgstr(s)]);
12.   {$ENDIF}
13.   st := 1;
14.   i := 1;
15.   nm[1] := 0; For l := 1 to 32 do nm[l] := 0;
16.   Result := 0;
17.   while i <= Length(s) do
18.   begin
19.     j := i;
20.     case s[i] of
21.       '+':
22.         nm[st - 2] := SumOrConcat(nm[st - 2], nm[st - 1]);
23.       ttOr:
24.         nm[st - 2] := nm[st - 2] or nm[st - 1];
25.       '-':
26.         nm[st - 2] := nm[st - 2] - nm[st - 1];
27.       '*':
28.         nm[st - 2] := nm[st - 2] * nm[st - 1];
29.       ttAnd:
30.         nm[st - 2] := nm[st - 2] and nm[st - 1];
31.       '/':
32.         if nm[st - 1] <> 0 then
33.           nm[st - 2] := nm[st - 2] / nm[st - 1] else
34.           nm[st - 2] := 0;
35.       '>':
36.         if nm[st - 2] > nm[st - 1] then nm[st - 2] := 1
37.         else nm[st - 2] := 0;
38.       '<':
39.         if nm[st - 2] < nm[st - 1] then nm[st - 2] := 1
40.         else nm[st - 2] := 0;
41.       '=':
42.         if nm[st - 2] = nm[st - 1] then nm[st - 2] := 1
43.         else nm[st - 2] := 0;
44. [color=blue]      ttNe:
45.         if nm[st - 2] <> nm[st - 1] then nm[st - 2] := 1
46.         else nm[st - 2] := 0;
47. [/color]      ttGe:
48.         if nm[st - 2] >= nm[st - 1] then nm[st - 2] := 1
49.         else nm[st - 2] := 0;
50.       ttLe:
51.         if nm[st - 2] <= nm[st - 1] then nm[st - 2] := 1
52.         else nm[st - 2] := 0;
53.       ttInt:
54.         begin
55.           v := nm[st - 1];
56.           if Abs(Round(v) - v) < 1e-10 then
57.             v := Round(v) else
58.             v := Int(v);
59.  
60.           nm[st - 1] := v;
61.         end;
62.       ttFrac:
63.         begin
64.           v := nm[st - 1];
65.           if Abs(Round(v) - v) < 1e-10 then
66.             v := Round(v);
67.  
68.           nm[st - 1] := Frac(v);
69.         end;
70.       ttRound:
71.       begin
72.         v := Round(Extended(nm[st - 1]));
73.         nm[st - 1] := v;
74.       end;
75.       ttUnMinus:
76.         nm[st - 1] := -nm[st - 1];
77.       ttUnPlus:;
78.       ttStr:
79.         begin
80.           if nm[st - 1] <> Null then
81.             s1 := nm[st - 1] else
82.             s1 := '';
83.           nm[st - 1] := s1;
84.         end;
85.       ttNot:
86.         if nm[st - 1] = 0 then nm[st - 1] := 1 else nm[st - 1] := 0;
87.       ttMod:
88.         nm[st - 2] := nm[st - 2] mod nm[st - 1];
89.       ' ': ;
90.       '[':
91.         begin
92.           k := i;
93.           s1 := GetBrackedVariable(s, k, i);
94.           if Assigned(FOnGetValue) then
95.           begin
96.             nm[st] := Null;
97.             {$IFDEF DebugLRCalcs}
98.             DebugLnEnter('TfrParser.CalcOPZ "[" -> FOnGetValue s1=%s',[s1]);
99.             {$ENDIF}
100.             FOnGetValue(s1, nm[st]);
101.             {$IFDEF DebugLRCalcs}
102.             DebugLnExit('TfrParser.CalcOPZ "[" <- FOnGetValue res=%s',[string(nm[st])]);
103.             {$ENDIF}
104.           end;
105.           Inc(st);
106.         end
107.       else ...
108.  

Code: Pascal  [Select][+][-]

1. callq  0x1000a2ef0 <SYSUTILS$_$EVARIANTERROR_$__$$_CREATECODE$LONGINT$$EVARIANTERROR>

[Guylain]

New informations about this problem:

As the report has a lot of data, I edited the XML file (.lrf), deleting all references to variables(about 1500 variables!), changing them to text, and keeping others text values, colors, shapes, etc.

Now i can process the report without problem, naturally without any real data from the "fruserdataset."

After that, I converted first item to data (eg.: "No" to "[No]'), and I'm still able to generate the report.

I will continue to recreate the data by group of ten and try until the report crashes.

So I will find the exact data entry invalid in Windows 11, but ok in Windows 10.

I'll keep you informed when I find it.

*** new (2021/12/26 19h52)
The crash begins to occur on a date field, even if i change the format in memo. Maybe Windows 11 regional settings have been modified.
Follow up soon

*** new (2021/12/26 21h17)
There is a crash for every memo with a format of type 'Number'.
I'm going to put instead a 'Text' format for every memo containing a 'Number' format.
Right now, for maybe 5 or 6 such fields, it works, and it crashes at the next memo with 'Number' format.

I remind you this report worked very well in Windows 10 with those 'Number' formatting

*** new (2021/12/28 14h18)
I 've deleted all formats made with format button in the memos, and if necessary added memo scripts with formatfloat instruction to get good looking numbers, and this way my report works with Windows 11.

*** new (2022-07-01 19h38)
After lots of forms editing, it happens the crash comes from the number separator ',': my Windows 11 system now has numbers with the ',' separator instead of the '.' in Windows 10, and my database is coded with '.' (DBF standard). So I can use format button with the ',' separator without problem.

I include part of DBF file as it is, and the stringgrid as decoded and the format needed