Recent

Author Topic: Lazarus Release Candidate 2 of 2.2.0  (Read 22784 times)

af0815

  • Hero Member
  • *****
  • Posts: 771
Re: Lazarus Release Candidate 2 of 2.2.0
« Reply #60 on: November 24, 2021, 10:19:07 am »
Lazarus 2.2.0RC2 (rev lazarus_2_2_0_RC2-0-gab85f43b84) FPC 3.2.2 i386-win32-win32/win64 have a Problem in TTabControl and Anchors in Frames (in Frames).

Is affected from this problem TTabControl causes ELayoutException in Frames (39478) - only on win32 have other people reported. it pops up with Lazarus trunk, but i have today tested RC2 is also affected. 

I have installed a new fpc stable and Lazarus 2.2.0 RC2 from scratch and tested with the attached layoutproblemWOfs.zip no other dependencies needed.

Run the program an change TS_DUT1 to TS_DUT2 and back - and the Exception raises. If you remove the Anchors from TTabControl it works.

---
Program was working in Lazarus 2.1.0 r65130 FPC 3.2.2 i386-win32-win32/win64

Links:
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39478

in German forum
https://lazarusforum.de/viewtopic.php?f=5&t=13936 we have discussed a possible solution, in TTabControlNoteBookStrings.TabControlBoundsChange there is possible that the position change for FNotebook is set wrong. The bounds not changed should be taken from FNotebook, not from TabControl, becaus this added a border. And then a loop is introduced.
« Last Edit: November 24, 2021, 10:21:42 am by af0815 »
regards
Andreas

Marc

  • Administrator
  • Hero Member
  • *
  • Posts: 2532
Re: Lazarus Release Candidate 2 of 2.2.0
« Reply #61 on: November 25, 2021, 11:52:32 am »
Attached is the editoroptions.xml for RC2 (cant attach .xml, so renamed it to .xml.pas).

Fixed this it, xml is allowed now

Marc
//--
{$I stdsig.inc}
//-I still can't read someones mind
//-Bugs reported here will be forgotten. Use the bug tracker

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 7520
  • Debugger - SynEdit - and more
    • wiki
Re: Lazarus Release Candidate 2 of 2.2.0
« Reply #62 on: November 25, 2021, 11:56:59 am »
Attached is the editoroptions.xml for RC2 (cant attach .xml, so renamed it to .xml.pas).

I set the selected language option and saved it.  Restarting lazaus and the gutter shows as grey  ;D.

Just for fun, I went and changed the gutter colour and selected scheme global. On restart the gutter colour was as selected (clyellow  %) ).

So it seems that having changed to language option, it all works correctly subsequently with either the language or scheme options.

I tried to reproduce (though on windows, but that should not matter...).  Tested the RC2 in 32 and 64bit.
Both worked with your xml.

* If you place the old xml back => does the error happen again?

* Did/Does the new/working config have significant diffs in the color section?

Just on the off chance that a wrong file was loaded....

If it still happens:
* Menu: View => IDE internals => About IDE
  What are the values for primary and secondary conf path?
  The only editoroptions.xml you have is in the secondary path? There is none in the primary?

   You may also get to see those pathes, if you start the IDE from a console. It should print them...

If it still happens:
* Do you start the "lazarus" exe directly, or do you start "startlazarus"?
   If the latter, does it make a diff if you directly start "lazarus" ?

If it still happens:
* If you change the font-size together with the color => is the font size correctly loaded?


Also, have you at some point rebuild you IDE? And if so, is your IDE build with -O2 or higher?

There is a bug in FPC (only O2 up), extremely hard to trigger (only known trigger is some code in fpdebug (using a generic from LclBase though), and only if the target is 64bit win, but other code, on other targets could trigger it in theory).
This is fixed in FPC 3.2.3 and 3.3.1 / For what I know, it was first seen in 3.2.0

timppl

  • Jr. Member
  • **
  • Posts: 80
Re: Lazarus Release Candidate 2 of 2.2.0
« Reply #63 on: November 26, 2021, 08:43:27 am »
Hi Martin

I have had a bit of a play. If I use the old xml file the error reappears, so I looked at the Color section.

There are a number of differences,
Working
Code: XML  [Select][+][-]
  1.     <Color Version="13">
  2.       <LangObjectPascal Version="13">
  3.         <ColorScheme Value="Twilight"/>
  4.         <SchemeTwilight>
  5.           <ahaGutter Background="clGray"/>
  6.         </SchemeTwilight>
  7.       </LangObjectPascal>
  8.       <Globals Version="13">
  9.         <SchemeTwilight>
  10.           <ahaGutter Background="clGray"/>
  11.         </SchemeTwilight>
  12.       </Globals>
  13.     </Color>
  14.  

Non-working
Code: XML  [Select][+][-]
  1.     <Color Version="13">
  2.       <LangObjectPascal>
  3.         <ColorScheme Value="Twilight"/>
  4.       </LangObjectPascal>
  5.       <Globals Version="13">
  6.         <SchemeTwilight>
  7.           <ahaGutter Background="clGray"/>
  8.         </SchemeTwilight>
  9.       </Globals>
  10.     </Color>
  11.  
so I manually edited the file to see if any were significant.
In short, if i delete the
Quote
Version="13"
from the "LangObjectPascal" section then the fault shows ( i.e. the gutter is black ); put it back in and it works correctly.

Deleting the "Globals" section in the working xml also puts the gutter to black, even though clGrey is also specified in the "ColorScheme" section.

All configuration is in the primary path, secondary path does not exist ( it is set to /etc/lazarus/ )

It is normally started from a desktop file which calls
Quote
Exec=/home/tim/misc/laztest/startlazarus --pcp=/home/tim/.config/laztest

Changing startlazarus to lazarus with the non-working config makes no difference to the bahavior, the gutter is still black.

HTH

Tim
Mageia 8 Linux on x86

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 7520
  • Debugger - SynEdit - and more
    • wiki
Re: Lazarus Release Candidate 2 of 2.2.0
« Reply #64 on: November 26, 2021, 10:47:01 am »
Created https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39489

I haven't checked if I can reproduce. But the description give a pretty good idea where to start.
It Might take a bit before I get to it...

Muso

  • Full Member
  • ***
  • Posts: 244
Re: Lazarus Release Candidate 2 of 2.2.0
« Reply #65 on: November 26, 2021, 10:44:27 pm »
I encounter a nasty regression:

- I compile projects last time compiled using 2.2.0 RC1 with
Lazarus 2.2.0RC3 (rev lazarus_2_2_0_RC2-49-gcbc6b141e2)
FPC 3.2.3 x86_64-win64-win32/win64

As result I get not tons of these changes to the .lfm file which are obviously wrong, see the attached screenshot.

is there a fix available or a workaround to prevent this issue?

Muso

  • Full Member
  • ***
  • Posts: 244
Re: Lazarus Release Candidate 2 of 2.2.0
« Reply #66 on: November 26, 2021, 10:49:18 pm »
is there a fix available or a workaround to prevent this issue?

there is: I change with a text editor
- LCLVersion = '2.2.0.2'
+ LCLVersion = '2.2.0.3'

Then no conversion for the .lfm file takes place and thus I can avoid the bug. however, it its clear that there might be a conversion for good reason, it is just that in the conversion is the bug.

Muso

  • Full Member
  • ***
  • Posts: 244
Re: Lazarus Release Candidate 2 of 2.2.0
« Reply #67 on: November 26, 2021, 11:37:48 pm »
There is an other regression to RC1:

I want to compile on release mode. For this mode I have the settings attached, so no debugger is used. But when I run my compiled result I am asked to set a debug option, see attached.

So why do I have to specify a debugger option despite no debugging is used?

Lazarus 2.2.0RC3 (rev lazarus_2_2_0_RC2-49-gcbc6b141e2)
FPC 3.2.3 x86_64-win64-win32/win64


Muso

  • Full Member
  • ***
  • Posts: 244
Re: Lazarus Release Candidate 2 of 2.2.0
« Reply #68 on: November 26, 2021, 11:42:33 pm »
there is: I change with a text editor
- LCLVersion = '2.2.0.2'
+ LCLVersion = '2.2.0.3'

This does not work. I now get also the attached. So the bug is not in the LFM file conversion.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 7520
  • Debugger - SynEdit - and more
    • wiki
Re: Lazarus Release Candidate 2 of 2.2.0
« Reply #69 on: November 27, 2021, 12:35:17 am »
I encounter a nasty regression:

- I compile projects last time compiled using 2.2.0 RC1 with
Lazarus 2.2.0RC3 (rev lazarus_2_2_0_RC2-49-gcbc6b141e2)
FPC 3.2.3 x86_64-win64-win32/win64

As result I get not tons of these changes to the .lfm file which are obviously wrong, see the attached screenshot.

Update your Fpc 3.2.3

The snapshot you have as a bug, and that leads to plenty of integer values being replaced with color names.


Be aware, that most likely once an lfm has been "corrupted" it can only be read with the faulty version that wrote it. So check, if you have backups.
« Last Edit: November 27, 2021, 12:37:53 am by Martin_fr »

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 7520
  • Debugger - SynEdit - and more
    • wiki
Re: Lazarus Release Candidate 2 of 2.2.0
« Reply #70 on: November 27, 2021, 12:53:54 am »
I want to compile on release mode. For this mode I have the settings attached, so no debugger is used. But when I run my compiled result I am asked to set a debug option, see attached.

So why do I have to specify a debugger option despite no debugging is used?

Setting "debug info" to none, does not mean to not have a debugger. (Though admittedly, it leaves the debugger *almost* useless).

With the "debug info" = none, I can
- compile
- run without debugger (from the menu)

Only when I do F9 (or normal "run"), which means run in the debugger, then the dialog comes.

Indeed, the old IDE did not care (and IIRC, if you switch the new IDE to use gdb, then it wont care either).
The old IDE did happily let you run your app in the debugger, without debug info present. That means all the debugger could do, is give you assembler, if you paused the app.

Assign a key to "run without debugger" and use that instead. Since you do not want to debug anyway.


Both behaviours have there pro and con.
- the old: if you really did just want to "run without debugger", you could ignore that there was a debugger present. In *most* cases it was unnoticeable.
- the new: if you do want to debug, its nice to know that you need to fix the settings.


Muso

  • Full Member
  • ***
  • Posts: 244
Re: Lazarus Release Candidate 2 of 2.2.0
« Reply #71 on: November 29, 2021, 03:01:13 pm »
Update your Fpc 3.2.3
The snapshot you have as a bug, and that leads to plenty of integer values being replaced with color names.

Thank you. I just did this an in case I still the bug, I will report this here.

Muso

  • Full Member
  • ***
  • Posts: 244
Re: Lazarus Release Candidate 2 of 2.2.0
« Reply #72 on: November 29, 2021, 03:41:53 pm »
- the old: if you really did just want to "run without debugger", you could ignore that there was a debugger present. In *most* cases it was unnoticeable.
- the new: if you do want to debug, its nice to know that you need to fix the settings.

Thanks for explanation. I  only did not expect such a change between two RC releases.

However, since I saw some debugger-related commits to the 2_2 branch, I upgraded my Laz to this (using FCUPDeluxe). But also with
Lazarus 2.2.0RC3 (rev lazarus_2_2_0_RC2-63-gc29da8f0d8)
FPC 3.2.3 x86_64-win64-win32/win64
I have an issue:

- In the debug settings I set the debug info type to Automatic, see screenshot attached.
- When I now run in debug mode I get a dialog in which I must specify the debug info type. When I cancel this dialog, the debugging is not started.

But isn't the Automatic setting thought to select automatically an appropriate debug info?
This issue appears for both possible debuggers (FPDebug and IDE default)

Besides this, where can I find kind on a comparison table
- between the "IDE default debugger" and "FPDebug"
- the different debug info type settings (Dwarf1, 2, 3 and Stabs)
« Last Edit: November 29, 2021, 04:02:28 pm by Muso »

Muso

  • Full Member
  • ***
  • Posts: 244
Re: Lazarus Release Candidate 2 of 2.2.0
« Reply #73 on: November 29, 2021, 04:01:39 pm »
I should also mention that the dialog on starting a debug session speaks about the FPDebug debugger, see attached. But I get this also when I use the "IDE default" debugger.

Is the "IDE default" debugger the same as the FPDebug debugger?

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 7520
  • Debugger - SynEdit - and more
    • wiki
Re: Lazarus Release Candidate 2 of 2.2.0
« Reply #74 on: November 29, 2021, 05:16:33 pm »
I should also mention that the dialog on starting a debug session speaks about the FPDebug debugger, see attached. But I get this also when I use the "IDE default" debugger.

Is the "IDE default" debugger the same as the FPDebug debugger?
Yes. Well the default depends on your OS. On Linux and Windows that is FpDebug (Since Laz 2.2RC - and already for some time in git)

More to the point: The default debugger is set under Tools > Options > Debugger Backend.
Whatever is selected there is the default.
In the project, you can then set a diff debugger for each project. E.g. if you have a project that you run on a remote machine, and you need a remote debugger, then you can (if you install it) set the gdb-remote debugger.

Also, this default is for new installations.
If you upgrade an existing config, it will keep your settings (which would be gdb, unless you never made any change, that saved any debugger specific config).


Thanks for explanation. I  only did not expect such a change between two RC releases.
This was already the case for RC1.

If indeed it did not happen to you, then maybe it used an old config of yours, that pointed to gdb?

Quote
I have an issue:

- In the debug settings I set the debug info type to Automatic, see screenshot attached.
- When I now run in debug mode I get a dialog in which I must specify the debug info type. When I cancel this dialog, the debugging is not started.

But isn't the Automatic setting thought to select automatically an appropriate debug info?
This issue appears for both possible debuggers (FPDebug and IDE default)
Ideally yes... But depends on who defines "appropriate"....

Automatic, just means that the IDE leaves the decision to FPC. So it means "use fpc default".
The fpc default depends on the target (OS, bitness, ...).

The IDE does not have a list of all the fpc-defaults. So it can't be sure if "automatic" resulted in use-able debug info (for gdb that did not matter, as all the types of debug info can be read by gdb / though some lead to more errors in gdb....).

Since FpDebug only read DWARF, but not stabs, it now needs one of the dwarf settings explicitly selected.

The fact that this leads to extra user-interaction (instead of having some default) is not great. But keeping gdb instead of FpDebug is not better.
Hopefully that can be improved..... But not sure when...

Quote
Besides this, where can I find kind on a comparison table
- between the "IDE default debugger" and "FPDebug"
- the different debug info type settings (Dwarf1, 2, 3 and Stabs)
The "default debugger" is not a specific type. See above.

But info on the different debuggers:  https://wiki.lazarus.freepascal.org/Debugger_Status

That does not list every single issue, every debugger has....
There is some background here (some is really related to GDB, other relates to all debuggers or the way FPC encodes debug info, or the debug info itself....)
https://wiki.lazarus.freepascal.org/GDB_Debugger_Tips

GDB has lots of issues with various Pascal data types and structures. Depending on the gdb version this leads from data not shown to crashes.
And we can't fix GDB.

FpDebug is not bug free either. But we can fix it, and it does deal with a lot more of the data types.

Stabs and Dwarf are how the compiler tells the debugger how the machine code relates to the Pascal source, and where/what/which variables, types, .... are to be found.
I don't have a list of all the diffs.
Also that would include what FPC actually uses of each feature set. And what the debugger can read of it.

 

TinyPortal © 2005-2018