So I am debugging an application that transfers data over a socket connection. I want to inspect received data so I put a breakpoint in the method that does the handling of the response. But when I get there and want to see what has been received Lazarus does not show it...

Here is what I do:

function TSSRemoteClient.StatusReadLog(DayNumber: integer; Body:
TStrings): boolean;
begin
  Result := false;
  if SendCommand(ccSTATLOG, 'DAY=' + IntToStr(DayNumber)) then
  begin
    WaitForResponse(ccSTATLOG);
    Body.Text := FRxArgs[ccSTATLOG];
    Result := Body.Count > 0;  //<== Put breakpoint here
  end;
end;

When I reach this breakpoint and I hover the mouse over Body.Text or Body.Count Lazarus shows a message saying:

Body.Text = Type TSTRINGS has no component named TEXT and
Body.Count = Type TSTRINGS has no component named COUNT

What is that?
If that was true then the code above would not even compile and here I am running into the line in the debugger...
Result is set to true so obviously Body.Count contains some number > zero.

If I hover over DayNumber instead then it resolves into 44103

Is there some setting I am missing to enable inspection of these kinds of data?

Its a property, and calls a getter function.

The debugger can not yet call any functions. So you can't inspect that property.

It goes a step further, FPC whilst compiling does not actually add debug info for this property either.
The dwarf standard (at least 2 or 3, need to check the higher ones) does not include the ability to describe properties. (and not sure, but stabs does probably neither, if it does fpc still does not use it)

Is there some setting I am missing to enable inspection of these kinds of data?

Unfortunately not....

Joost started working on extending fpdebug to do function calls. But its not yet available.
(I did see it "working" for functions that 1: take no arguments 2: return basic types like integer only, 3: do not raise exceptions or errors 4: do not have user set breakpoints in the code while being called ....)

And there are more issues up the road.
- AFAIK: Calling a function that returns a string (GetText) needs a hidden var param in which the result will be returned.
- Getting a string back, will cause a mem leak, unless the debugger can get enough info to decrement the strings reference

So there is a lot of work ahead
- Getting function calls to work in generic
- fpc to add debug info for such properties (potentially via custom extensions to the dwarf standard)
- fpc to add debug info for managed types (custom extensions to the dwarf standard)

For a Stringlist, you can inspect individual "items".

Using the "debug inspector" you can click through (mylist.FLIST)^[0].FSTRING

GDB may not be able to do this (not sure, but faint memory....) FpDebug can do this (at least in trunk)

Does Lazarus offer the functionality Delphi has (since quite some time, I might add): custom debug info visualizers ?

See

http://docwiki.embarcadero.com/RADStudio/Sydney/en/Debugger_Visualizers

Seems like a useful addition.
Don't know if it is technically feasible, though.

Michael.

Yes, I implemented them, IIRC. Don't remember the details, though. I added TDate, TDateTime and TTime formatters. It was quite a simple addon, should be easy to find in the sources.

The problem of object-based visualizers like a visualizer for TStrings is that your Lazarus IDE has to be compiled with the same FPC version/codebase that you also use for the debugged program. In Delphi this is usually the case (if you don't fiddle with RTL sources to fix bugs). In FPC/Lazarus this doesn't need to apply. I usually build Lazarus IDE less frequently than I update and build FPC trunk. Or you can build Lazarus with FPC stable but develop applications with FPC trunk. In that case such additions are unsafe.

Ondrej

Good news :-)

How to activate them ? Because everywhere I tried, a TDateTime is still displayed as a float: 44104.47848875 does not look like a date/time I can recognize... :-)

I tried tooltip evaluation, evaluate/modifiy, inspect, local variables, watches. None of them seems to use this.

I understand this need to keep versions aligned, but for the average user who simply installs Lazarus, this will always be the case: they get lazarus/FPC bundled.

In this matter the Laz/FPC developers are the exception. (one could think "it's their own fault that they make it difficult" ;-) )

So with this caveat in mind, I think support for object-based visualizers should definitely be added. Lazarus can easily enough detect that the version of FPC it uses for a project differs from the FPC version the IDE was compiled with, and disable the object-based visualizers.

Michael.

Strange, they are enabled by default. They get activated in
ide\debugmanager.pas :
constructor TDebugManager.Create(TheOwner: TComponent);
//...
   RegisterValueFormatter(skSimple, 'TDate', @DBGDateTimeFormatter);
   etc.

Tooltip evaluation: works for me
Watches: works for me
Local Variables: doesn't work for me - strange, I have to re-check. I thought it worked here.
Inspect: OK, I forgot about this one
Evaluate/modify: forgot about this one as well - but probably we need the reversed function as well to be able to write the modified formatted value back.

I probably said bullshit here. We get the detailed information about the object contents from the debugger, we don't use the object directly. So it should be possible with different FPC/RTL versions. This, of course, needs a much more sophisticated visualizer support in the IDE than there currently is. But that should be not really hard to make.

Ondrej

Locals do not have the type info

Gdb returns them as just a pair of name value strings.

Of course the backend could run each of them a watch. That will be a bit slower though.
Also that will need update of the debugger-intf. IIRC locals do not have the storage for the extra info.

The current debugger-intf really is just an extraction of the gdbmi-based interface
Now that fpdebug matures, it will be time to change it. If there is interest of any one to work on it, I have some ideas....

Aahhh, thanks - I remember now. I did it for locals (I obtained the type info for every locals entry) but it made debugging so painfully slow that I reverted it.

Thanks for the info - I don't have to check now again.

Ondrej

Well the solution here would be that, once the gdbmi-debugger  get to idle (and if the user has not pressed continue/run/step) then it could start fetching more info on locals.
But that would need to be driven by the backend.
And it would mean that the storage for locals need to be changed, so the backend can store the info.

If the debugger intf is changed, fpdebug can supply the info and it can do so real fast.
But the intf changes need to be done careful....

When I posted this thread there were a lot of responses that went way above my head...
Now I am debugging the application where the state of some buttons are set depending on conditions.

But again I am unable to inspect what the button state is when I have stopped on a breakpont in the code.

One simple example:

procedure TfrmSSRemoteClient.elvTasksItemSelect(Sender: TObject; Item:
TListItem; Index: Integer);
begin
  btnDeleteTask.Enabled := true;
  btnTaskProperties.Enabled := true;
  btnEditTask.Enabled := true;
  btnStopTask.Enabled := Item.SubItems[1] = '1';
  btnRunNow.Enabled := Item.SubItems[1] = '0';
end;

For example if I step through this simple piece of code and hover on the Enabled keyword on the line above or on the same line there is only a message popping up:
Type TBITBTN has no component named ENABLED.....

According to my memory Enabled for buittons has existed from Delphi1 and onwards and I am pretty sure that it also exists in Lazarus/FPC... Why can I not see the state of the buttons while debugging?

I am using Lazarus 2.0.8/FPC 3.0.4 on Windows 10 installed using the official installer.

Please help with whatever customization I need to do in Lazarus to enable this seemingly natural function while debugging!

It is driving me nuts.

Bo Berglund wrote

Type TBITBTN has no component named ENABLED.....

Enabled is a *property*

Fpc currently does not add debug-info for can
inspect only fields and variables.

The only exception is: when the project (or package) settings specify "dwarf" debug info type *AND* the property does not have a "getter function", but instead directly accesses the field "read FEnabled".

------------
Unfortunately the debugger can not yet call functions (e.g. GetEnabled) yet. Work for this is in progress, as part of fpdebug. But not yet use-able.