Recent

Author Topic: Local Vars often inspect with an error message  (Read 910 times)

SandyG

  • Jr. Member
  • **
  • Posts: 92
Local Vars often inspect with an error message
« on: September 11, 2024, 01:50:50 am »
When debugging code and trying to inspect local variables I end up often with this message

'XXX = <Error: Failed to read data from register>'

Where XXX is the name of a local variable. I assume that it's a variable that is getting put into a register but should not be a reason to not be able to inspect the value. Typically the variable type is a 'Single' floating point, where Integer types always seem to work fine.

Any tricks to make the debugger see these floating point values correctly?
I currently have to create a string variable, and convert the float to a string, then can debug inspect the string. Pain.

Running Windows 11,
Lazarus 3.0 (rev lazarus_3_0) FPC 3.2.2 x86_64-win64-win32/win64

I have tried both -O and -O1 optimizations and makes no difference, as well as messing with the Dwarf type, both 2 and 3. But doesn't seem to matter.

Am I missing a setting?

Thanks

Sandy



Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 10454
  • Debugger - SynEdit - and more
    • wiki
Re: Local Vars often inspect with an error message
« Reply #1 on: September 11, 2024, 11:05:07 am »
An example (such as that I can compile and test on my Machine) would be good.

I assume you are using "FpDebug"? => Tools > Options > Debugger Backend


One Idea: You say you tried -O- and -O1 => Are those variables/procedures in the project code, or are you calling a function in a package (e.g. LCL)? If it is a package, then make sure to replicate that setting for the package (as packages have their own settings / Can be forced by "Additions and Overrides").


You may try the GDB backend. Just to confirm if it makes a change.

SandyG

  • Jr. Member
  • **
  • Posts: 92
Re: Local Vars often inspect with an error message
« Reply #2 on: September 11, 2024, 07:41:12 pm »
Yes, shows up as FpDebug for the backend.

the -O and -O1 are the optimization levels on the project options for 'Optimization Levels' and it doesn't seem to matter.

The code that is being debugged is a component, but it gets recompiled each time. I will double check that the component library settings are OK too, ie, optimization level and related to see if that makes any difference. That could be the area where something is not set for debugging as I'm currently looking at my project and debugging the component as it's being used in the project (hope that makes sense). So may be something related to compile/debug options in the BGRAComponent build that is possibly not set up for debugging.

If I can't find anything odd I'll try a simple program to see if I can duplicate it.

Thanks for the quick reply!

Sandy

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 10454
  • Debugger - SynEdit - and more
    • wiki
Re: Local Vars often inspect with an error message
« Reply #3 on: September 11, 2024, 08:01:55 pm »
Other things to look out for... They should all work, but may hold clues:

- When the error happen, is the top stack selected?
  I.e. in the stack-window the green arrow (or yellow arrow in breakpoint) in the left-most column is at stack 0 (zero)
  For this NOT to be the case, would usually mean that you changed it.
- Is the correct stack selected (an exception may internally stop at fpc_raiseexception, but the debugger shows your code)
  Though if other locals work then that should be the case

Also: Are you in a "nested" procedure? (A procedure declared inside another procedure)?
Or are you inside a "finally" block?


At the time of it happening, can you open the "Register window" (menu View > Debug Windows) and see which registers are there? (looking for RSP and RPB or on 32 bits ESP and EPB)

Can you open the asm window and copy the asm (plus/minus 10 lines) for the code where you are paused (assuming that this code actually accesses the local variable)



As I write this I just realize:

Local vars that are not accessed in code may not be present in the exe. But since you try to get a value of it, that seems unlikely to be the cause.

And variables marked as "threadvar" may not be accessible at all, but I would probably expect a different error.

SandyG

  • Jr. Member
  • **
  • Posts: 92
Re: Local Vars often inspect with an error message
« Reply #4 on: September 11, 2024, 08:25:50 pm »
Martin -

The debugging issue does not happen as a result of an error, I typically set a breakpoint on a line of code and when it hits, I look around at some variables. No thread vars, nothing like that. No nested procedures either.

Example code below where I see the issue, note that in this case the variables can be computed and optimized away I'm guessing, but this still happens in other places of the code. I will try to work up a more concrete and stand alone example to see if I can make something you can try as well.

Code: Pascal  [Select][+][-]
  1. procedure TDTCustomThemedGauge.DrawMarker;
  2. var
  3.   Origin: TDTOrigin;
  4.   mask: TBGRABitmap;
  5.   x1, y1, x2, y2: integer; //These can be looked at when hovering during a breakpoint
  6.   j, value : single;           // Can't look at (error display when hovering) or evaluate these in the debugger inspector
  7.  
  8. begin
  9.  
  10.   // skip drawing if nothing changed or not drawn
  11.  
  12.   if (not FMarkerSettings.Dirty) then
  13.     Exit;
  14.  
  15.   FMarkerSettings.Dirty := False;
  16.  
  17.     // Now, if not enabled we can leave if flag reset!
  18.  
  19.   if not FMarkerSettings.Enabled then
  20.     exit;
  21.  
  22.   Origin := Initializebitmap(FMarkerBitmap, Width, Height);
  23.  
  24.   j := (180 - 270) / 2;
  25.  
  26.   if MarkerSettings.Style = msCenter then
  27.     begin
  28.         // draw a downward pointing triangle and border
  29.  
  30.         if FRangeLEDSettings.Style = lsFlat then
  31.           begin
  32.  
  33.         value := 25;  // hack test
  34.  
  35.       /// Draw center line of triangle for starters
  36.       // 25 test angle in degrees
  37.  
  38.         x1 := Origin.CenterPoint.x - Round(FMarkerSettings.Radius * cos((j + value * 270 / FMaxValue) * Pi / 180));
  39.         y1 := Origin.CenterPoint.y - Round(FMarkerSettings.Radius * sin((j + value * 270 / FMaxValue) * Pi / 180));
  40.  
  41.       // Calculate draw to point top
  42.  
  43.         x2 := Origin.CenterPoint.x - Round((FMarkerSettings.Radius - FMarkerSettings.Height) * cos((j + value * 270 / FMaxValue) * Pi / 180));
  44.         y2 := Origin.CenterPoint.y - Round((FMarkerSettings.Radius - FMarkerSettings.Height) * sin((j + value * 270 / FMaxValue) * Pi / 180));
  45.  
  46.         FMarkerBitmap.LineCap := pecSquare;
  47.         FMarkerBitmap.DrawLineAntialias(x1, y1, x2, y2, FMarkerSettings.Color, FMarkerSettings.Width);
  48.       end;
  49.     end;
  50. end;
  51.  

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 10454
  • Debugger - SynEdit - and more
    • wiki
Re: Local Vars often inspect with an error message
« Reply #5 on: September 11, 2024, 08:47:23 pm »
Couple of other things that can be done.

1) Run the IDE
Code: Text  [Select][+][-]
  1. lazarus.exe --debug-log=c:\path\to\log.txt  --debug-enable=
  2. DBG_VERBOSE,DBG_WARNINGS,DBG_ERRORS,DBG_VERBOSE_BRKPOINT,DBG_STATE,DBG_EVENTS,DBG_COMMAND_ECHO,DBG_FPDEBUG_VERBOSE,FPDBG_BREAKPOINTS,FPDBG_COMMANDS,FPDBG_THREADS,FPDBG_QUEUE

Slight chance the logfile will have something.

Additional an exe (or objdump) may help. Either would allow me to see the actual debug info for the local var, and from that check if I can figure something out.
With that I would need
- name of the unit and function
- name of the local var

A compiled exe can be send to my private email.
Or you can run objdump on it yourself (and zip the result)
Code: Text  [Select][+][-]
  1. /objdump.exe --dwarf=info project1.exe > dwarf.txt



EDIT

The data will be huge, but you can also check yourself
Code: Text  [Select][+][-]
  1.  <2><13e18f>: Abbrev Number: 7 (DW_TAG_subprogram)
  2.     <13e190>   DW_AT_name        : FormCreate
  3.  
  4. ...
  5.  
  6.  <3><13e1e0>: Abbrev Number: 10 (DW_TAG_variable)
  7.     <13e1e1>   DW_AT_name        : value
  8.     <13e1e7>   DW_AT_location    : 2 byte block: 90 19  (DW_OP_regx: 25 (xmm8))
  9.     <13e1ea>   DW_AT_type        : <0x13eb91>
  10.  

Here the variable is called "value"

And if location contains DW_OP_regx then that is not currently supported (not sure if gdb does / gdb 12 seems to do it)

Usually I would not expect that with -O- or -O1

(unless you enable -ooregvar or have a directive to enable it in the code)
« Last Edit: September 11, 2024, 09:08:06 pm by Martin_fr »

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 10454
  • Debugger - SynEdit - and more
    • wiki
Re: Local Vars often inspect with an error message
« Reply #6 on: September 11, 2024, 08:58:22 pm »
Btw, I can get the same error by compiling with -O2
And integer vars are readable, though the correctness of the value is (probably) pure luck in that case.


With O2 the value is indeed stored in a register. And FpDebug only reads from the integer registers.
But that is not helpful, as fpc does not  (or did not, last time I checked) write enough debug info to deal with a register being used for different vars at different lines of code.

SandyG

  • Jr. Member
  • **
  • Posts: 92
Re: Local Vars often inspect with an error message
« Reply #7 on: September 13, 2024, 05:21:45 am »
I built a simple program that had a few integers, singles, and some code that adds and displays the results in the caption of a Label.

Tried a bunch of different ways to make it NOT work, and it always inspected the single variables just fine.

I also looked at the settings for the component library and it had a setting of optimization of NONE, but I need to make sure that it's really the case. The code that is being debugged is my changes to a component in the package and I know that is a fresh compile, but maybe something else is going on that is compiling with -O2 as a compiler setting.

I have not had a chance to logfile with the command line as you gave, will try to get a chance to do it this weekend.

Sandy

 

TinyPortal © 2005-2018