Recent

Author Topic: Lazarus Release Candidate 3 for 2.0  (Read 103840 times)

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9794
  • Debugger - SynEdit - and more
    • wiki
Re: Lazarus Release Candidate 3 for 2.0
« Reply #105 on: January 14, 2019, 02:41:59 pm »
In latest lazarus, i have a issue with debugger not really working on any variables - i've attached a picture, this is stock install: Lazarus 2.0.0RC3 r59877 FPC 3.0.4 i386-win32-win32/win64

Compared to the same app of yours under
- a previous 2.0rc
- 1.8.6

In either case, since this looks like a gdb issue: gdb has not changed. (And neither has fpc, in case it is the generated debug info)

I can not reproduce this.  Do you have an example how to reproduce?

Also to gather the details, I am not clear from your description what you use?
- I assume you have a 64bit windows /64bit cpu ?
- You are using the 64 or 32bit IDE? You did / didn't install and use the cross compiler for the other bitness?

Are you using "Dwarf2 with  sets" ? "Dwarf 3" may cause errors like the one you describe, and that may happen seemingly at random.

What are your optimization settings? (O0 or O1 ?). And double-check smart-linking is off.

Out of interest does it happen to:
- local var
- parameters (without const, constref, var or out)
- parameters with const, constref, var or out  (the 0x40 may be because of "const")
  ("const" may happen at random, since fpc may encode it different, depending on type)
- class fields
- globals
?

If it is the const modifier, adding a watch ^widechar(Text)^ may help.


Note, that if it worked, widestring is known to the debugger as ^widechar (that is what fpc writes into the debuginfo). That means that de-ref Text^ will/should show you ONE char. That is a known issue, and unless gdb changes something, that may be hard to fix. But that is widestring related.


On Win64 with 64 bit target apps, it is known that there is an issue (either in fpc or gdb) where changes at one bit of code (in any unit) can cause issues with single stepping in another unit. But so far this only affected single stepping. (And this happens with all versions of GDB, and according to latest reports maybe with lldb too) https://bugs.freepascal.org/view.php?id=34159



You may want to try with alternate versions of GDB (It's a matter of finding some time, and then they will be added to the default install, but not 2.0 anymore)

It does not matter if you cross compile or not. It only matters if you app (the target) is 32 or 64 bit. (And according to that place the gdb.exe in the mingw/i386-win32/bin or mingw/x86_64-win64/bin folder in your lazarus install dir)

64 bit:
https://sourceforge.net/projects/lazarus/files/Lazarus%20Windows%2064%20bits/Alternative%20GDB/

32 bit:
https://sourceforge.net/projects/lazarus/files/Lazarus%20Windows%2032%20bits/Alternative%20GDB/

Start with the 8.2 version.
But keep in mind, that sometimes earlier versions work better than the latest.



MrShoor

  • New Member
  • *
  • Posts: 11
Re: Lazarus Release Candidate 3 for 2.0
« Reply #106 on: January 14, 2019, 07:13:11 pm »
Do you have an example how to reproduce?
I don't know about JernejL's case, but I can provide an example when GDB totally doesn't work.
You just need to declare a nested class with interface implementation and store this nested class as interface variable. Then no one private field of this class can be watched.
Here a minimal sample:
Code: Pascal  [Select][+][-]
  1. program Project1;
  2.  
  3. {$mode objfpc}{$H+}
  4.  
  5. uses
  6.   SysUtils, Classes;
  7.  
  8. type
  9.   TMyClass = class
  10.   private type
  11.  
  12.     IInternalIntf = interface
  13.       function Eval: Integer;
  14.     end;
  15.  
  16.     TInternalClass = class (TInterfacedObject, IInternalIntf)
  17.     private
  18.       FVal: Integer;
  19.     public
  20.       function Eval: Integer;
  21.       constructor Create(const AValue: Integer);
  22.     end;
  23.  
  24.   private
  25.     FObj: IInternalIntf;
  26.   public
  27.     procedure DoTest;
  28.     constructor Create;
  29.   end;
  30.  
  31. { TMyClass.TInternalClass }
  32.  
  33. function TMyClass.TInternalClass.Eval: Integer;
  34. begin
  35.   Result := FVal * FVal;
  36. end;
  37.  
  38. constructor TMyClass.TInternalClass.Create(const AValue: Integer);
  39. begin
  40.   FVal := AValue;
  41. end;
  42.  
  43. { TMyClass }
  44.  
  45. procedure TMyClass.DoTest;
  46. begin
  47.   WriteLn(FObj.Eval);
  48. end;
  49.  
  50. constructor TMyClass.Create;
  51. begin
  52.   FObj := TInternalClass.Create(13);
  53. end;
  54.  
  55. procedure Test1;
  56. var obj: TMyClass;
  57. begin
  58.   obj := TMyClass.Create;
  59.   try
  60.     obj.DoTest;
  61.   finally
  62.     FreeAndNil(obj);
  63.   end;
  64. end;
  65.  
  66. begin
  67.   Test1;
  68.   ReadLn;
  69. end.
  70.  
Just try to set a breakpoint at Result := FVal * FVal; line, and watch FVal. You will get no symbol BLABLA in current context. This is a really annoying bug.
« Last Edit: January 14, 2019, 07:14:48 pm by MrShoor »

avra

  • Hero Member
  • *****
  • Posts: 2514
    • Additional info
Re: Lazarus Release Candidate 3 for 2.0
« Reply #107 on: January 14, 2019, 10:33:29 pm »
Incompatible PPU problem:

In short, I have some NewPackage that uses already compiled/installed OldPackage. When I try to install NewPackage Lazarus complains that PPU from OldPackage is not compatible, but source PAS file can not be found (it is there and I can recompile OldPackage by hand without problems) so NewPackage fails on compilation.

Right now I can not build an embedded form editor (sparta_dockedformeditor or sparta_smartformeditor), but I think the problem is more generic since I have seen it with other components too, as explained here: https://forum.lazarus.freepascal.org/index.php/topic,43646.msg306307.html#msg306307

Problem shows on fpcupdeluxe generated 32bit Lazarus 2.0 fixes (currently RC3) with FPC 3.0 fixes (currently 3.0.5 SVN59943M) running on Win10x64. If needed I can put an archive of more then 600MB to some site (it will work on any Windows pc when put into proper dir and run with a provided shortcut). Building fails with Normal IDE profile without any extra compilation switches. Other profiles including some custom ones tried with the same result.

If anyone else can confirm this then I will file a bug report.
ct2laz - Conversion between Lazarus and CodeTyphon
bithelpers - Bit manipulation for standard types
pasettimino - Siemens S7 PLC lib

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9794
  • Debugger - SynEdit - and more
    • wiki
Re: Lazarus Release Candidate 3 for 2.0
« Reply #108 on: January 14, 2019, 10:50:20 pm »
I don't know about JernejL's case, but I can provide an example when GDB totally doesn't work.
You just need to declare a nested class with interface implementation and store this nested class as interface variable. Then no one private field of this class can be watched.

Just try to set a breakpoint at Result := FVal * FVal; line, and watch FVal. You will get no symbol BLABLA in current context. This is a really annoying bug.

That appears to be an issue in FPC.

FPC does not generate debuginfo for TInternalClass. (Afaik that happens because no variable of this type is declared).

- It generates "line info", but that only tells the debugger how to map the address to a line.
- In the line info it encodes a function name as P$PROJECT1$_$TMYCLASS_$_TINTERNALCLASS_$__$$_EVAL$$LONGINT
  Which you can also see in the stack window.

Code: [Select]
#0 P$PROJECT1$_$TMYCLASS_$_TINTERNALCLASS_$__$$_EVAL$$LONGINT at :36
#1 DOTEST(0xfcab0) at project1.lpr:48
#2 TEST1 at project1.lpr:61
#3 main at :0

It does however NOT tell the debugger to which object this function belongs.
In fact it does not include any information about the class  TInternalClass at all. (So according to the debug info created by fpc, FVal does not exist).


You can work-around this by including a field
  FDummy: TInternalClass;
in the outer class.


There is nothing that can be done in the IDE.
This needs to be fixed in fpc.

Please report this as an issue with FPC on the bugtracker.

It appears the issue is also present with FPC trunk (about 2 weeks old).



BeniBela

  • Hero Member
  • *****
  • Posts: 905
    • homepage
Re: Lazarus Release Candidate 3 for 2.0
« Reply #109 on: January 14, 2019, 10:57:05 pm »
  • I also do not see any resolved symbols in the backtrace dialog, only the addresses.
  • Something is wrong with the painting. Controls (TCustomHeaderControl, TScrollBar, ...) that are children of a TCustomControl (my treelistview) are not always painted  anymore. The situation in the attachment happened when minimizing/opening the form. 
  • Something  has gone weird  with modal form. Sometimes do not appear or only appear after a few minutes, and then they cannot be closed anymore 

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9794
  • Debugger - SynEdit - and more
    • wiki
Re: Lazarus Release Candidate 3 for 2.0
« Reply #110 on: January 14, 2019, 11:07:35 pm »
Incompatible PPU problem:

This is definitely an issue in fpc. I seen this (or similar) a long time ago (but in the realm of 3.0.2 or 4). But its a long time, since 3.0.4 was released (or even longer since the 3.0 branch was started). So no idea if this is fixed in trunk.

It does not say "incompatible". It says "Checksum changed"
Quote
(3104) Compiling lazarus.pp
(10001) PPU Loading C:\PRG\Lazarus\FixesAll\lazarus\components\sparta\mdi\lib\i386-win32\sparta_multiplyresizer.ppu
(10011) PPU Source: sparta_multiplyresizer.pas not found
(10028) Recompiling sparta_MultiplyResizer, checksum changed for Generics.Collections
C:\PRG\Lazarus\FixesAll\lazarus\ide\sparta_multiplyresizer.pas(80,12) Fatal: (10022) Can't find unit sparta_MultiplyResizer used by sparta_MDI
Fatal: (1018) Compilation aborted

The subsequent error "Can't find unit sparta_MultiplyResizer" is to be expected.
The unit (source code) was only in the path, when the package containing it was (re-)build.
When "lazarus.pp" is compiled (as stated by the log), packages have long been build. The IDE passes only the path to the ppu files to the compiler. So the compiler does not know where the source file is.


Anyway the issue is with Generics.Collections (and/or the package that contains it)

There may be many reasons for this error.
The one I know, and have seen before is a combination of using "inline" and "circular unit refs" .

Something todo, with one of the circular referencing units forces the other (or itself) unit to compile again, but not updating its checksum. Or maybe it was changing the checksum for the header, after discovering the "inline".

1)
I am not sure, it may be enough to make sure, that all "inline" are declared in the interface. Yet it may not.

2)
It should help, if you disable all inlining in the affected units (package of Generics.Collections)

3)
It may (or may not) also help, to compile this package twice (the 2nd time, without cleaning it). The 2nd compile may fix the checksums.


--
It is quite some time, since I had the problem, so all this from distant memory.
It could also be another issue (not related to inline) that ends with the same error.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9794
  • Debugger - SynEdit - and more
    • wiki
Re: Lazarus Release Candidate 3 for 2.0
« Reply #111 on: January 14, 2019, 11:12:18 pm »
  • I also do not see any resolved symbols in the backtrace dialog, only the addresses.
More info?

The stacktrace window is directly provided by GDB, so not much the IDE can do about.

One note though. If the objects/data on the stack  (the param of the function) are allocating huge memory, then they may not get resolved. The memory limit can be adjusted on the debugger page under Tools>Options (in the property grid on the debugger page)

avra

  • Hero Member
  • *****
  • Posts: 2514
    • Additional info
Re: Lazarus Release Candidate 3 for 2.0
« Reply #112 on: January 18, 2019, 02:57:37 pm »
It does not say "incompatible". It says "Checksum changed"
Sorry if provided info was not enough. Incompatible PPU is mentioned as fatal error during IDE rebuilding:
Quote
sparta_multiplyresizer.pas(80,12) Fatal: Cannot find sparta_MultiplyResizer used by sparta_MDI, incompatible ppu=C:\Prg\Lazarus\FixesAll\lazarus\components\sparta\mdi\lib\i386-win32\sparta_multiplyresizer.ppu, package sparta_MDI

Anyway the issue is with Generics.Collections (and/or the package that contains it)

There may be many reasons for this error.
The one I know, and have seen before is a combination of using "inline" and "circular unit refs" .

Something todo, with one of the circular referencing units forces the other (or itself) unit to compile again, but not updating its checksum. Or maybe it was changing the checksum for the header, after discovering the "inline".

1)
I am not sure, it may be enough to make sure, that all "inline" are declared in the interface. Yet it may not.

2)
It should help, if you disable all inlining in the affected units (package of Generics.Collections)

3)
It may (or may not) also help, to compile this package twice (the 2nd time, without cleaning it). The 2nd compile may fix the checksums.
As for point 3 I have set manual compilation of package rebuild options in both generics.collections and sparta_DockedFormEditor, but still the same problem. Messing with points 1 and 2 is uncharted territory for me, so I will byte them only if no other option is left.

Interesting thing is that I have now reinstalled everything from scratch, and at first docked form editor installed and worked (although embedded form editing didn't work when smart form editor package was also installed), but after 10-15 installed packages I got the same IDE rebuild error that sparta_multiplyresizer.ppu is incompatible. After uninstalling all sparta packages problem was gone and I could continue with other packages, but embedded form editing is lost.

To me, not having a functional docked form editor is a major bummer and I will report it as a bug in Lazarus 2.0 RC3 / FPC 3.0.5.
ct2laz - Conversion between Lazarus and CodeTyphon
bithelpers - Bit manipulation for standard types
pasettimino - Siemens S7 PLC lib

avra

  • Hero Member
  • *****
  • Posts: 2514
    • Additional info
Re: Lazarus Release Candidate 3 for 2.0
« Reply #113 on: January 19, 2019, 12:55:29 am »
not having a functional docked form editor is a major bummer and I will report it as a bug in Lazarus 2.0 RC3 / FPC 3.0.5.
Just reported: https://bugs.freepascal.org/view.php?id=34899
ct2laz - Conversion between Lazarus and CodeTyphon
bithelpers - Bit manipulation for standard types
pasettimino - Siemens S7 PLC lib

Akira1364

  • Hero Member
  • *****
  • Posts: 561
Re: Lazarus Release Candidate 3 for 2.0
« Reply #114 on: January 19, 2019, 11:30:33 pm »
Note that Generics.Collections has been in trunk FPC for over a year now, and the Lazarus version is somewhat outdated compared to the trunk version. Anyone having problems might want to try replacing their files with the ones from trunk. (Personally, I've never had any problems with Sparta Docked Form Editor at all.)

avra

  • Hero Member
  • *****
  • Posts: 2514
    • Additional info
Re: Lazarus Release Candidate 3 for 2.0
« Reply #115 on: January 20, 2019, 02:54:08 am »
Note that Generics.Collections has been in trunk FPC for over a year now, and the Lazarus version is somewhat outdated compared to the trunk version. Anyone having problems might want to try replacing their files with the ones from trunk.
I replaced all generics.*.pas files from \lazarus\components\sparta\generics\source with \fpcsrc\packages\rtl-generics\src ones from trunk downloaded at the beginning of December, and after manual successful recompiling of sparta_generics.lpk, sparta_mdi.lpk, and sparta_dockedformeditor.lpk, I added sparta_dockedformeditor package to IDE and tried IDE clean rebuild but error was the same (incompatible ppu):
Quote
Warning: Recompiling sparta_MultiplyResizer, checksum changed for Generics.Collections
sparta_multiplyresizer.pas(80,12) Fatal: Cannot find sparta_MultiplyResizer used by sparta_MDI, incompatible ppu=C:\PRG\Lazarus\FixesAll\lazarus\components\sparta\mdi\lib\i386-win32\sparta_multiplyresizer.ppu, package sparta_MDI

Personally, I've never had any problems with Sparta Docked Form Editor at all.
First thing I do on fresh Lazarus is to add anchor docking package and sparta docked form editor. That goes well and embedded form editor works. But after installing more and more packages, at one moment (maybe at installing something that uses generics?) I am not able to rebuild the IDE any more because of the reported error. If I uninstall sparta docked form editor package I can rebuild IDE and continue with installation of other packages.
ct2laz - Conversion between Lazarus and CodeTyphon
bithelpers - Bit manipulation for standard types
pasettimino - Siemens S7 PLC lib

avra

  • Hero Member
  • *****
  • Posts: 2514
    • Additional info
Re: Lazarus Release Candidate 3 for 2.0
« Reply #116 on: January 22, 2019, 09:33:26 pm »
In 32-bit Lazarus 2.0 RC3 and FPC 3.0.5 on Win10x64, when I right click on some tab in source editor and choose 'Close Page' menu with item tab is not closed. With Ctrl+F4 or File / Close Page tab gets closed. Can someone confirm this?
ct2laz - Conversion between Lazarus and CodeTyphon
bithelpers - Bit manipulation for standard types
pasettimino - Siemens S7 PLC lib

Xor-el

  • Sr. Member
  • ****
  • Posts: 404
Re: Lazarus Release Candidate 3 for 2.0
« Reply #117 on: January 22, 2019, 10:17:32 pm »
In 32-bit Lazarus 2.0 RC3 and FPC 3.0.5 on Win10x64, when I right click on some tab in source editor and choose 'Close Page' menu with item tab is not closed. With Ctrl+F4 or File / Close Page tab gets closed. Can someone confirm this?

works fine in 64-bit Lazarus 2.0 RC3 and FPC 3.2.0 on Win10x64

ASBzone

  • Hero Member
  • *****
  • Posts: 678
  • Automation leads to relaxation...
    • Free Console Utilities for Windows (and a few for Linux) from BrainWaveCC
Re: Lazarus Release Candidate 3 for 2.0
« Reply #118 on: January 23, 2019, 10:30:19 pm »
In 32-bit Lazarus 2.0 RC3 and FPC 3.0.5 on Win10x64, when I right click on some tab in source editor and choose 'Close Page' menu with item tab is not closed. With Ctrl+F4 or File / Close Page tab gets closed. Can someone confirm this?

Hey, @Avra

I'm running 32-bit Lazarus 2.0 RC3 (upgraded from RC2) with FPC 3.04 on Windows 10, and the "Close Page" works fine for me.

Just tested.
-ASB: https://www.BrainWaveCC.com/

Lazarus v2.2.7-ada7a90186 / FPC v3.2.3-706-gaadb53e72c
(Windows 64-bit install w/Win32 and Linux/Arm cross-compiles via FpcUpDeluxe on both instances)

My Systems: Windows 10/11 Pro x64 (Current)

BeniBela

  • Hero Member
  • *****
  • Posts: 905
    • homepage
Re: Lazarus Release Candidate 3 for 2.0
« Reply #119 on: January 23, 2019, 10:40:11 pm »
  • I also do not see any resolved symbols in the backtrace dialog, only the addresses.
The stacktrace window is directly provided by GDB, so not much the IDE can do about.

I think in this case it was because  the entire stack trace only had addresses in fpc's rtl

In 32-bit Lazarus 2.0 RC3 and FPC 3.0.5 on Win10x64, when I right click on some tab in source editor and choose 'Close Page' menu with item tab is not closed. With Ctrl+F4 or File / Close Page tab gets closed. Can someone confirm this?

I have another problem.

When I right click on some tab, there is no menu.

Not always. I just started Lazarus, closed like 5 tabs from the menu, and then the menu no longer appeared. Actually no popupmenu anywhere in Lazarus appears anymore. Not even the recent files from the toolbar. Nor the copy Lazarus version to clipboard menu.

Sometimes it also had happened  with older Lazarus.




And once the RC crashed, when I pressed Ctrl+O to open a file.

 

TinyPortal © 2005-2018