Lazarus Release 2.2.0

[Martin_fr]

unfortunately the debug do not allow me to step in the procedure (as I put a breakpoint Lazarus show it as unreachable)

Did you recompile the package with debug info? (dwarf)

[dbannon]

Yes, I agree, first place I would look is at -

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

1.   if FInputLines_SHARED <> nil then FInputLines_SHARED.free;
2. ....
3.   if FLines_SHARED<> nil then FLines_SHARED.free;

Has FInputLines_SHARED or FLines_SHARED been freed but not set to nil ?  Free-ing something does not set it to nil. Speaking as someone who has done it lots of times !

Davo

[Jurassic Pork]

hello,
i have found a doscommand for Lazarus (changed the original DosCommand (Delphi) to Lazarus) here and in this version the destructor is :

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

1. destructor TDosCommand.Destroy;
2. begin
3.   if FThread <> nil then Stop;
4.   if FTimer <> nil then FTimer.free;
5.   FSync.Free;
6.   FInputLines_SHARED.free;
7.   FLines_SHARED.free;
8.   inherited;
9. end;

as you can see no test if nil on FSync,  FInputLines_SHARED, FLines_SHARED.

Friendy J.P

[duzenko]

Kudos to the unnamed hero, who brought us "Run to Cursor"

[DragoRosso]

Removed (RXDBGRID compilation with Lazarus 2.2.0). New post: https://forum.lazarus.freepascal.org/index.php/topic,57815.0.html

Sorry for OT.

[JuhaManninen]

@DragoRosso, please start a new forum thread about your RX package issues.
This thread is about Lazarus Release.

[Jurassic Pork]

Hello,

I know,

I try to replicate with a minimum amount of code but it works.

I have a component inherited from TDOSComand that I found in www.torry.net.

My component just call inherited in the destroy. The destroy in TDOSComand is

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

1. destructor TDosCommand.Destroy;
2. begin
3.   if FThread <> nil then Stop;
4.   if FTimer <> nil then FTimer.free;
5.   if FSync <> nil then FSync.Free;
6.   if FInputLines_SHARED <> nil then FInputLines_SHARED.free;
7.   if FLines_SHARED<> nil then FLines_SHARED.free;
8.   inherited;
9. end;  
10.  

unfortunately the debug do not allow me to step in the procedure (as I put a breakpoint Lazarus show it as unreachable)

it seems that it is the debugger on 2.2 version of lazarus that causes the problem  :

no problem with version 2.0.12  when exiting a doscommand test program.
no problem when exiting a doscommand test program without debug in 2.2 version of Lazarus.
Access violation when exiting a doscommand test program with debug in 2.2 version of Lazarus (see attachment).

Friendly, J.P

[nouzi]

Thanks for all

[Jurassic Pork]

Hello,

I know,

I try to replicate with a minimum amount of code but it works.

I have a component inherited from TDOSComand that I found in www.torry.net.

My component just call inherited in the destroy. The destroy in TDOSComand is

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

1. destructor TDosCommand.Destroy;
2. begin
3.   if FThread <> nil then Stop;
4.   if FTimer <> nil then FTimer.free;
5.   if FSync <> nil then FSync.Free;
6.   if FInputLines_SHARED <> nil then FInputLines_SHARED.free;
7.   if FLines_SHARED<> nil then FLines_SHARED.free;
8.   inherited;
9. end;  
10.  

unfortunately the debug do not allow me to step in the procedure (as I put a breakpoint Lazarus show it as unreachable)

it seems that it is the debugger on 2.2 version of lazarus that causes the problem  :

no problem with version 2.0.12  when exiting a doscommand test program.
no problem when exiting a doscommand test program without debug in 2.2 version of Lazarus.
Access violation when exiting a doscommand test program with debug in 2.2 version of Lazarus (see attachment).

Friendly, J.P

the access violation comes with the terminate of the FThread :

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

1. procedure TDosCommand.Stop;
2. begin
3.   if (FThread <> nil) then
4.   begin
5.     FThread.FreeOnTerminate := true;
6.     FThread.Terminate; //terminate the process
7.     FThread := nil;
8.   end;
9. end;    

[Jurassic Pork]

Hello,

I know,

I try to replicate with a minimum amount of code but it works.

I have a component inherited from TDOSComand that I found in www.torry.net.

My component just call inherited in the destroy. The destroy in TDOSComand is

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

1. destructor TDosCommand.Destroy;
2. begin
3.   if FThread <> nil then Stop;
4.   if FTimer <> nil then FTimer.free;
5.   if FSync <> nil then FSync.Free;
6.   if FInputLines_SHARED <> nil then FInputLines_SHARED.free;
7.   if FLines_SHARED<> nil then FLines_SHARED.free;
8.   inherited;
9. end;  
10.  

unfortunately the debug do not allow me to step in the procedure (as I put a breakpoint Lazarus show it as unreachable)

it seems that it is the debugger on 2.2 version of lazarus that causes the problem  :

no problem with version 2.0.12  when exiting a doscommand test program.
no problem when exiting a doscommand test program without debug in 2.2 version of Lazarus.
Access violation when exiting a doscommand test program with debug in 2.2 version of Lazarus (see attachment).

Friendly, J.P

the access violation comes with the terminate of the FThread :

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

1. procedure TDosCommand.Stop;
2. begin
3.   if (FThread <> nil) then
4.   begin
5.     FThread.FreeOnTerminate := true;
6.     FThread.Terminate; //terminate the process
7.     FThread := nil;
8.   end;
9. end;    

With this code no more problem :

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

1. procedure TDosCommand.Stop;
2. begin
3.   if (FThread <> nil) then
4.   begin
5.     FThread.FreeOnTerminate := true;
6.     If not FThread.Finished then  FThread.Terminate; //terminate the process
7.     FThread := nil;
8.   end;
9. end;

[Igor Kokarev]

Many thanks for your hard work on Lazarus 2.2!

[mischi]

I am happy to announce that the macports packages are also updated to Lazarus 2.2.0 and fpc 3.2.2, including arm.

MiSchi

[Nicola Gorlandi]

Many Thanks to all,

I appreciate.

The change below fix the issue

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

1. If not FThread.Finished then  FThread.Terminate; //terminate the process

In order to do it by my own, how do you debug this issue ? Are you using the log or what else ?

[Martin_fr]

With this code no more problem :

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

1. procedure TDosCommand.Stop;
2. begin
3.   if (FThread <> nil) then
4.   begin
5.     FThread.FreeOnTerminate := true;
6.     If not FThread.Finished then  FThread.Terminate; //terminate the process
7.     FThread := nil;
8.   end;
9. end;

Actually: "No problem that you have spotted yet.

The code has a race condition. So there is a problem.

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

1.     FThread.FreeOnTerminate := true;

After that line, when the thread does end, it will free the TThread object. That is the object to which FThread points.

So, from this point on, FThread should be treated as a "dangling pointer". Because it can change into that, at any point.

Of course, if you could guarantee that the thread can not finish.... But since you check in the next line, if it has finished, clearly you can not guarantee this.

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

1.     If not FThread.Finished then  FThread.Terminate; //terminate the process

So you call "Finished", but the object (pointed to by FThread), may already have been destroyed. The result may be random, or the call may even crash.

And even, if the call is made on a still existing object, that is no good, because the object can be freed between the return from "Finished" and the access to "Terminate". Same dangling pointer issue here.


And mind "FThread <> nil" does not help either. After all a dangling pointer is a non-nil value.
And even if the thread would set FThread to nil, before destroying the object. Still a race condition. Still could happen between your check, and the "then" action that requires the check....
 

[Gald]

It looks like I'm the only one with this trouble.

Project > New Project > Run > Image related.
It can't run my old projects too. I can't run anything.

I've updated it from Lazarus 2.0.12.
What did I do wrong?