System crash with ShowMessage

[MaxCuriosus]

After adding about 7000 short strings to a TStringList variable, say SL, I've tried to view them with a ShowMessage(SL.Text) but the system crashes. Is this to be expected because of the large amount of strings or is it a bug?

Deb9 / Laz2.0.2 / FPC3.0.4 / gtk2

[Martin_fr]

Good question. Could be any number of things.
Not sure how much gtk is involved. Or how it deals with what I guess is a rather long string for a message dlg.

You could try to add a memo, and do memo.text := sl.text

[MaxCuriosus]

After a few simple tests I've observed that the threshold for crashing is around 52k for both the ShowMessage and Memo. Note that's not a hard crash requiring a reboot but rather a soft one that allows me to regain control after a few odd graphics things and perhaps via a user login form. Memo seems to be a little more friendlier in that respect.

[winni]

Hi!

Strange, strange!

I am just running a test. Adding a stortstring with the length of 60 in an infinite loop to a Memo. And let a Label show the length of the Memo.text.

In the moment the test reached just 6 MB and is still running.

My system is Lin64, Suse Tumbleweed, Lazarus 2.08, fpc 3.04, 64 Bit

Winni

PS.: Just 6.3 MB

[Thaddy]

Show us some code...

[winni]

Hi!

This testcode reached just the upper limit 10 000 000 bytes with no problems:

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

1. procedure TForm1.Button1Click(Sender: TObject);
2. var s : ShortString;
3.     i : integer;
4. begin
5. setLength(s,60);
6. s[60] := ' ';
7. while length (Memo1.Text) <10000000 do
8.    begin
9.    for i := 1 to 59 do s[i] := chr(Random(96)+32);
10.    memo1.lines.add(s);
11.    Label1.Caption := IntToStr(Length(Memo1.Text));
12.    application.ProcessMessages;
13.    end;
14. end;                                                      
15.  

With the application.ProcessMessages that takes some time.

Winni

[lucamar]

A memo shouldn't give any problem with a meagre 7K lines.

ShowMessage, though, is meant to show a relatively short text and not only is it quite limited but depends heavily on the facilities of the window or composition manager.

In this machine, for example, a 64KiB message is about the limit, and the window occupies almost the whole screen; a few more lines and not only crashes the application, but also Metacity (the composition/theme manager) itself. It might be due to a buffer overflow, overflows when calculating the size and/or position of the messsage window, or a miriad other things, but the underlying reason is that the widget isn't meant for that.

If you really need to show such a big message you'd better write your own message dialog using controls (like TMemo) able to handle such quantities of text.

[Martin_fr]

After a few simple tests I've observed that the threshold for crashing is around 52k for both the ShowMessage and Memo. Note that's not a hard crash requiring a reboot but rather a soft one that allows me to regain control after a few odd graphics things and perhaps via a user login form. Memo seems to be a little more friendlier in that respect.

If it crashes a with memo at 52k, then there is a bug somewhere.

And, Stringlist and memo have been around a long time. So I would think it highly likely that the bug is in your code.

Or maybe you have special chars (like #0) in your text. Not sure what a memo will do with that (under gtk2).

Or bad UTF-8?

[winni]

Or maybe you have special chars (like #0) in your text. Not sure what a memo will do with that (under gtk2).

Or bad UTF-8?

No - very stable!

If you assign values from random (256) to every char the Memo behaves very kind:

* Due to the illegal values it slows down horrible
* Every value  <32  and >127 is shown through the utf8 substitute sign with the 4 hex values

Awful slow! Now at byte ~ 20 000

Talking about gtk2

Winni

[MaxCuriosus]

If it crashes a with memo at 52k, then there is a bug somewhere.

And, Stringlist and memo have been around a long time. So I would think it highly likely that the bug is in your code.

I will probably agree, but the "Memo" code has since been removed from the project where it was embedded, so I can't point to what was my probable mistake.

On the other hand in a stand-alone test the "ShowMessage" consistently fails from around 52k, and the "Memo" works properly and fast. See code below.

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

1. procedure TForm1.Button1Click(Sender: TObject);
2. const
3.   S='012345678901234567890123456789012'; { 33 characters }
4.   NbLines=1600; { OK at 1600, crash at 2000 }
5. Var
6.   SL: TStringList;
7.   I,TotBytes: Integer;
8. begin
9.   SL:=TStringList.Create;
10.   TotBytes:=0;
11.   For I:=1 to NbLines do
12.    Begin
13.      SL.Add(S);
14.      TotBytes:=TotBytes+Length(S)+1;
15.    end;
16.   ShowMessage('TotalBytes='+IntToStr(TotBytes));
17.   ShowMessage(SL.Text);
18. //  Memo1.Text:=SL.Text;
19.   SL.Free;
20. end;

[jamie]

If it crashes a with memo at 52k, then there is a bug somewhere.

And, Stringlist and memo have been around a long time. So I would think it highly likely that the bug is in your code.

I will probably agree, but the "Memo" code has since been removed from the project where it was embedded, so I can't point to what was my probable mistake.

On the other hand in a stand-alone test the "ShowMessage" consistently fails from around 52k, and the "Memo" works properly and fast. See code below.

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

1. procedure TForm1.Button1Click(Sender: TObject);
2. const
3.   S='012345678901234567890123456789012'; { 33 characters }
4.   NbLines=1600; { OK at 1600, crash at 2000 }
5. Var
6.   SL: TStringList;
7.   I,TotBytes: Integer;
8. begin
9.   SL:=TStringList.Create;
10.   TotBytes:=0;
11.   For I:=1 to NbLines do
12.    Begin
13.      SL.Add(S);
14.      TotBytes:=TotBytes+Length(S)+1;
15.    end;
16.   ShowMessage('TotalBytes='+IntToStr(TotBytes));
17.   ShowMessage(SL.Text);
18. //  Memo1.Text:=SL.Text;
19.   SL.Free;
20. end;

I would wager it would survive up to around ~1870

[winni]

Hi!

What are you doing?
I have set NbLines to 10 000 and there is no crash.
This results in 340 000 bytes

The only problem is, that you need an OK button on top - and not at bottom.

So the bug must be elsewhere.

Made a slightly shortened code:

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

1.  procedure TForm1.Button2Click(Sender: TObject);
2.     const
3.       S='012345678901234567890123456789012'; { 33 characters }
4.       NbLines=10000; { No crash }
5.     Var
6.       SL: TStringList;
7.       I: Integer;
8.     begin
9.       SL:=TStringList.Create;
10.       For I:=1 to NbLines do
11.        Begin
12.          SL.Add(S);
13.        end;
14.       sl.Insert(0,IntToStr(Length(sl.Text)) );
15.       ShowMessage(SL.Text);
16.       SL.Free;
17.     end;                  

Winni

[MaxCuriosus]

I have attached the complete stand-alone test progam.

With "Deb9/Laz2.0.2/FPC3.0.4/gtk2" configuration the crash occurs consistently from about 56,100 bytes, 1650 lines in the test program.

With "Win8/Laz1.8.0/FPC3.0.4" configuration the same program behaves properly with much more bytes, 3,500,000 bytes (100,000 lines) for exemple.

So I reiterate my original question, is this a bug in Lazarus/Pascal?

[winni]

Hi!

I Just tested your code with Laz 2.08/fpc3.04 64 Bit on Linux Suse Tumbleweed.

No problems, even if I set Nblines to 20 000.

ShowMessage and the stringlist exist since the very early days of Lazarus.
So it is not probable that there is a bug .

You never told us with which message the system crashes.

So it is hard to say what the reason is:
Bad Lazarus/ fpc installation?
Bad gtk installation?
Some Debian problems?
Or even hardware problems?

Winni

[MaxCuriosus]

Further tests.

1) With the same code as attached in Reply #12, the executable will also crash on a different computer with Deb9 Live, Deb10 Live or Tails4.5, however with different thresholds.

2) After the upgrade from Laz2.0.2 to Laz2.0.6 the same crashes occur.

3) If the executable is not run directly but with the debugger (F9), the debugger console shows a series of messages and the system hangs for a while. After regaining control I was able to take a screenshot of the debugger console (see attachment). Can somebody help me analyse these messages?