Recent

Author Topic: Re: debugger issues with structures  (Read 341 times)

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 11361
  • Debugger - SynEdit - and more
    • wiki
Re: debugger issues with structures
« on: May 10, 2025, 12:10:48 pm »
One of the few issues I currently have with Codetools is that it reports "TStringBuilder not found" while typing,

Indeed...

Code: Pascal  [Select][+][-]
  1. program Project1;
  2. uses SysUtils;
  3. var a: TStringBuilder;
  4. begin
  5. end.

You should report that.





Quote
The only thing buggy is the debugger when I try to get a variable's value, especially with record or class references. So I use writeln() frequently and hit ctrl+alt+o after execution end to check the output. That works very well.

If you talk about properties with getter function:
Code: Pascal  [Select][+][-]
  1. property Foo: T read GET_VALUE;
This is a known issue. (Though in some cases you can call "GET_VALUE" from the watches window / of course with all side effects of the function call).

Otherwise: OS ? Bitness?

What is your "Debugger Backend" configuration?
Menu: Tools > Options  (On Mac: Preferences > ...)
Page: Debugger > Debugger Backend

If your CPU is x86 or i386 (or M1..M3 on Mac) then it should be: "FpDebug internal Dwarf debugger" (or on Mac "LLDB + FpDebug")

Your "project options", on the page debugging should have "Dwarf 3" selected.

https://wiki.lazarus.freepascal.org/Debugger_Setup



I have no problems inspecting classes or records. And also not with pointers (or pointer to pointer to...) of them.

But if your debugger backend is "GDB" then you may indeed have issues with such pointers.
If you must stay with GDB, make sure to use "Dwarf 2 with sets". It wont solve all issues, but it usually works better with GDB than Dwarf-3.



There are issues with
Code: Pascal  [Select][+][-]
  1. type TFoo=object
  2.   FVal: integer;
  3.   procedure Bar;
  4. end;

While in a function of such an object (while such an object is "self") it can not be inspected. It can be, if it is another variable. To inspect it as self, you need FPC 3.3.1



If you have interfaces, then you can use
   :i2o(myintf)

https://wiki.freepascal.org/FpDebug-Watches-Intrinsic-Functions#I2O(interface)_{show_object_behind_an_interface}
requires Lazarus 4.0 and FpDebug (not sure if it will work on Mac)



If you have "Sender: TObject" then you can't (should be obvious) do: Sender.FTag

TObject does not have FTag.

However if you add it as watch, and you have "use instance class" enabled (can be set to be enabled by default, under Tools>Options), then it will show the whole object.
Then you can expand it with the [ + ] button, and drag and drop the sub-watch FTag to the top level of the watches tree. (drag and drop needs the mouse to be over the TEXT of the watch-name.

You can also directly enter, e.g.: TButton(Sender).FTag

Or if you don't know the class, if the class may change (and if you use FpDebug) you can enter:  :cc(Sender).FTag
See the link above for description of :cc


If you have multiple classes of the same name but in different units, then the debugger may take anyone of them. In that case (with FpDebug) you can try to prefix them with the unitname: UnitFoo.TMyClass(Foo).FField
« Last Edit: May 10, 2025, 12:15:41 pm by Martin_fr »

Thaddy

  • Hero Member
  • *****
  • Posts: 17207
  • Ceterum censeo Trump esse delendam
Re: debugger issues with structures
« Reply #1 on: May 10, 2025, 12:39:45 pm »
Why would I report someting like that if classes is not included in the uses clause and neither {$mode delphi} nor {$mode objfpc} is specified.....
That would be a bin report.....
When specified, code simply works.
Laziness or spring flue.
Due to censorship, I changed this to "Nelly the Elephant". Keeps the message clear.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 11361
  • Debugger - SynEdit - and more
    • wiki
Re: debugger issues with structures
« Reply #2 on: May 10, 2025, 01:11:05 pm »
Why would I report someting like that if classes is not included in the uses clause and neither {$mode delphi} nor {$mode objfpc} is specified.....
That would be a bin report.....
When specified, code simply works.
Laziness or spring flue.
Ignored.

munair

  • Hero Member
  • *****
  • Posts: 884
  • compiler developer @SharpBASIC
    • SharpBASIC
Re: debugger issues with structures
« Reply #3 on: May 10, 2025, 04:17:48 pm »
It's only logical.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 11361
  • Debugger - SynEdit - and more
    • wiki
Re: debugger issues with structures
« Reply #4 on: May 10, 2025, 04:21:57 pm »
Well...
The important part is the type alias in line 339 of sysstrh.inc. It's simply that Lazarus CodeTools had/has problems if there is a temporary define with the same name in the same unit which is why that was changed. So yes, with the current version of FPC there shouldn't be a problem anymore.

Maybe newer versions of FPC will not have the code that makes codetools fail. But Codetools shouldn't fail in first.

Codetools should find it even with the old fpc code.

 

TinyPortal © 2005-2018