FPC 3.2.2 - get crash only when not using writeln - strange ?

[paule32]

Hello,
I have following Code, and get in touch of trouble when not using writeln ...

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

1. type
2.   PStringListArray = ^TStringListArray;
3.   TStringListArray = array[0..0] of String;
4.  
5. type
6.   TStringList = class(TObject)
7.   private
8.     FItems: PStringListArray;
9.     FCount: Integer;
10.   protected
11.     procedure  Grow;
12.    ...
13.   end;
14.  
15. function SetStringListLength(var Arr: PStringListArray; oldsize, newsize: Integer): PStringListArray; stdcall; export;
16. var
17.   NewMem: PStringListArray;
18.   CopyCount, i: Integer;
19. begin
20.   GetMem  (NewMem , NewSize * sizeof(Integer));
21.   FillChar(NewMem^, NewSize * sizeof(Integer), 0);
22.   writeln('set 1');
23.   if (Arr <> nil) then
24.   begin
25.   writeln('set 2');
26.     CopyCount := oldsize;
27.     if newsize < oldsize then
28.     CopyCount := NewSize;
29.     writeln('set 3');
30.     for i := 0 to CopyCount - 1 do
31.     NewMem^[i] := Arr^[i];
32.     writeln('set 4');
33.     FreeMem(Arr);
34.     writeln('set 5');
35.   end;
36.   writeln('set 6');
37.   Arr := NewMem;
38.   writeln('set 7');
39.   result := Arr;
40. end;

// with this version, I get a crash of the application

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

1. procedure TStringList.Grow;
2. begin
3. //  writeln('coun: ' + inttostr(FCount));
4.   SetStringListLength(FItems, FCount, FCount + 1);
5.   FItems[FCount] := 'test';
6.   writeln('====> ' + FItems^[FCount]);
7.   inc(FCount);
8. end;

// with this Version all is working fine

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

1. procedure TStringList.Grow;
2. begin
3.   writeln('coun: ' + inttostr(FCount));
4.   SetStringListLength(FItems, FCount, FCount + 1);
5.   FItems[FCount] := 'test';
6.   writeln('====> ' + FItems^[FCount]);
7.   inc(FCount);
8. end;

do I something missing ?

[Martin_fr]

You are storing strings, presumingly ansistrings, which makes it pointers that go into the array.

You calculate the length based on sizeof(integer). Which for 64 bit will not work. At 32 bit it will work, but that is by chance...

The access past allocated memory may have worked at random...

Use valgrind memcheck...

[Nicole]

I crash by using writeln as long as I can think (started with Lazarus 2 on Win 7)

[paule32]

may be a Windows GUI Problem.
When you have compile GUI, it is not guranteed that the TUI Mode works - because the GUI Thread's that will be blocked if you use TUI console Members...

[gues1]

may be a Windows GUI Problem.
When you have compile GUI, it is not guranteed that the TUI Mode works - because the GUI Thread's that will be blocked if you use TUI console Members...

I crash by using writeln as long as I can think (started with Lazarus 2 on Win 7)

You can use (under Windows):

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

1.       if GetConsoleWindow = 0 then
2.         begin
3.           AllocConsole;
4.         end;
5.  

This create a new console if no other is present. You can use that when you needed it.

[jcmontherock]

It's more easy to use dynamic arrays.

[Thaddy]

It has nothing to do with dynamic arrays as such. It has to do with stdin/out/err or in real Pascal Output/Input and ErrOutput handles missing in GUI Apps.
That can be mitigated by creating a console:
As suggested above by creating a console in code
Or as I suggested previously: {$apptype console}
It is also a Windows only issue.
On Windows write/writeln/read/readln need console handles.
You can also redirect the console handles: that would be the better option.

I actually consider this a bug in Lazarus for the Windows versions, but the Laz developers do not agree.
In unix there is no problem, since the handles are always there and can be handled (sic) as if a file.
The latter can be /dev/null since that is a "file" stored in oblivion. Windows has no direct equivalent. (well, it has, but needs some stiff coding)

You can defer to wsprintf as an alternative without writing too much code:
You can make it look like write/writeln...,,

[paule32]

- I remove all *.a, *.o, *.ppu and *.bak Files
- then I compile each File alone with -gl and then dwarf unit not found
- then I compile each File with -Ur and get the same size for EXE and DLL

before this all, I compile the system.pas with -Us
and then, I can use ppu and o Files without pas source files.

- I check the Code and set a condition to each writeln

- at compile time the Framework I use define DLLEXPORT
- at compile time the Application I use define DLLIMPORT

Then I had to "forward" declared members from the DLL in several pas sources.

All in one, I can use binary Form only - but then I have a monolith Version of DLL and EXE.

When I compile the Framework with -B and without -Ur I get smaller EXE and bigger DLL.
That is fine - the relevant parts can be outsourced in a DLL

FPC 3.2.2 produce *.a rchive files which can be used later for a second Application to refer the Symbols to the DLL.

I think, I should stop or make a break there in this Posting because it was a cross pointing Posting.

Thanks all to the replies