Print Page - static REGLOC <error reading variable>

Free Pascal => Beginners => Topic started by: Birger52 on August 12, 2020, 02:12:28 pm

Title: static REGLOC <error reading variable> - debug error?
Post by: Birger52 on August 12, 2020, 02:12:28 pm

I'm getting the error in the attached image.

A settings editor, for 4 apps working together, communicating via SimpleIPC.
A procedure shows the editor-form - reads data as they are, and compares after editing - and distributes messages as required to the apps.

Code: Pascal [Select][+]

procedure EditSettings(aSender:TForm;aP:Tpoint;aCl:TSimpleIPCClient);
var
  setForm : TSettingsForm;
  sSet, nSet : TSetSet; // sSet is settings before they are changed - used to determine what needs to be updated
 
  procedure SendIPCMsg(aMsg, IPCId:string);
  begin  // Sends msgs using aCl - the IPC Client of the app that activated the editor
  ...
  end;
 
begin
  SetForm := TSettingsForm.Create(aSender);
  aP.X := aP.X - SetForm.Width;
  SetForm.Left := aP.X;
  SetForm.Top := aP.Y;
  SetForm.ShowModal;
  sSet := TSetSet.Create;
  sSet.ReadSet;
  nSet := SetForm.edtSet;
  nSet.WriteSet;
  if nSet.BoolChrs <> sSet.BoolChrs then begin // Alert Apps that use boolChrs
    // ... Send IPC to other apps
  end;
  if nSet.ToMetric <> sSet.ToMetric then
    // ... Send IPC to other apps
  if (nSet.StoreTiming <> sSet.StoreTiming) or (nSet.PlayTimerInterval <> sSet.PlayTimerInterval) then
     // ... Send IPC to other apps
  if (nSet.PlayAuto <> sSet.PlayAuto) or (nSet.PlayAutoInterval <> sSet.PlayAutoInterval) then
    // ... Send IPC to other apps
  if (nSet.HistoryRec <> sSet.HistoryRec) and (nSet.HistoryAnt <> sSet.HistoryAnt) then
     // ... Send IPC to other apps
{
  if (nSet.IgnoreCards <> sSet.IgnoreCards) and (nSet.IgnoreModels <> sSet.IgnoreModels) then
    saveSet := true;
  Ignore Cards and Ignore models used solely by DBupdater - and is not yet implemented.
}
  SetForm.Free; // also frees nSet
  sSet.Free;
end;
 

It compiles fine - but does not produce expected results.
f.eks. sSet.PlayAuto (boolean) is 240 - sSet.PlayAutoInterval (int) is -MaxInt is what it looks like.
In contrast nSet have the correct values (default as assigned in object, edited or read from registry).

Singlestepping to locate error, I get the attached message (static REGLOC <error reading variable>) for sSet - but nSet is just fine.
Also I get an debug message in the TSetSet object when closing reigstry key
(reg.CloseKey - \"finish\" not meaningful in outermost frame.)..?
Image attached and so is unit that defines the TSetSet object.

Anybody know what's going on?
And/or how to correct whatever it is that is wrong?

Title: Re: static REGLOC <error reading variable> - debug error?
Post by: Birger52 on August 13, 2020, 11:51:44 am

Tried moving the comaprison and sending af messages to the form, when clicking the button that closes the editor.
It does the same thing.
One of the TSetSet objects it knows - the other it don't, and values are neither default nor the ones read from registry.

Title: Re: static REGLOC <error reading variable> - debug error?
Post by: Birger52 on August 13, 2020, 01:24:18 pm

Downgraded to when things were last functining - Lazarus 2.08 -fpc 3.0.4.
Needed to "Clean Up and Buikd" as the FPC 3.2.0 version of TSimpleIPCServer has a "Threaded" property, that doesn't exists in 3.0.4.
Things are functioning as expected.
Don't know if this is Lazarus or FPC - but something is obviously not going according to plans.

Title: Re: static REGLOC <error reading variable> - debug error?
Post by: Martin_fr on August 13, 2020, 02:40:34 pm

Quote

Also I get an debug message in the TSetSet object when closing reigstry key
(reg.CloseKey - \"finish\" not meaningful in outermost frame.)..?

Did that happen during a "step over" (F8)?
Or did you do "Step out" (Shift F8) ?

If they first: Do you have (Tools > Options > Debugger > prop-grid) "FixIncorrectStepOver" enabled?

There is an issue (either FPC, or GDB - could be either), which leads to gdb stepping into, when it should step over.
The IDE fixes that by issuing a "step out" (internally "step finish").
But given that something already got wrong with where a function begins, it could be that in your case the "step out" fails....

This issue can be triggered by changes in unrelated code. Maybe because code changes move addresses and their relative distance... (just wild guessing)....
So then 3.2 could just have triggered it in that code, but 3.0.4 probably can too, if other code changes.

How is TSetSet declared?

"REGLOC" is a class variable?
Or is this an old style object?

Would either sset or nset be nil at the time?

Title: Re: static REGLOC <error reading variable> - debug error?
Post by: Birger52 on August 13, 2020, 03:41:50 pm

TSetSet is in the file settingsset.pas, attached to the first post.
It is a descendant of TObject - and holds booleans, integer and strings read from registry - with some tweaks to make sure they have default values, if they are not found in registry.

I have the "FixIncorrectStepOver" checked - actually tried to uncheck it, and it makes no difference.

REGLOC must be something in debugger (or linker/compiler) - it's no invention of mine.

None of them are nil.
Initially both variables read the values from registry (and they are there - and are correct).
And both objects seem to be getting the correct values, inside the ReadSet() of the TSetSet object (F7 Step Into).
But once the ReadSet() procedure that reads values from registry to variables in object returns, one of the variables have values that are wrong (in many ways - a boolean have value true in one and 243 in the other, an integer that is defined and in registry as value 3, suddently has a value if -11 millions)

I tried to comment out the CloseKey of TRegistry - it is called by OpenKey, so it should make no functional difference - and it does not make any difference, except the message from the compiler doesn't show up.
(Indicating a problem in the 3.0.10 version of TRegistry?)
Values are still terribly wrong, outside the ReadSet() procedure...

The odd thing is, that it is the same class - the same code, that sometimes does right and sometimes wrong.

So looks more like the reference to the one of the variables is lost (REGLOC)...
But I have no idea....

Title: Re: static REGLOC <error reading variable> - debug error?
Post by: Martin_fr on August 13, 2020, 05:00:07 pm

Quote from: Birger52 on August 13, 2020, 03:41:50 pm

REGLOC must be something in debugger (or linker/compiler) - it's no invention of mine.

This is

Code: Pascal [Select][+]

  private const
    RegLoc = '\Software\SDC\Play';

I tested with fpc 3.2 and 3.0.4 with different gdb versions. For me all of them return the error.
Unfortunately, as soon as gdb reports that error, it appears to stop reading the entire object => So you never see the other fields.

It seems even fpdebug is currently troubled by this. But fpdebug continues with the other fields.

Quote

Values are still terribly wrong, outside the ReadSet() procedure...

If your setup somehow continues to the next field, then what does it print for RegLoc?
The issue is, if gdb did still have an error on that field (but continued...), then the remaining output may still be affected by that error.

On a first glance (but I need to look at details) the debug info generated by fpc seems to be correct. If that is the case, the error is in gdb.

2.0.10 came with a different gdb version. That has been rolled back. 2.2 will have the old gdb again (though for diff reasons).
However that old gdb fails in my tests too....

If the error is in gdb, then there is little hope of it getting fixed.

Title: Re: static REGLOC <error reading variable> - debug error?
Post by: Birger52 on August 14, 2020, 11:17:12 am

Ok.
RegLoc is mine - loacation in Registry. - was thrown off by capitals (and static and variable - my RegLoc is (defined as) a constant... :o)

But if it for some reason doesn't know where to look for the values, it makes sense it doesn't get the correct values. But not that singlestepping finds the values.

As you may have seen (https://forum.lazarus.freepascal.org/index.php/topic,51010.0.html), I downgraded to 2.0.8 - fpc 3.0.4, and here the same code function as it should.

I'll try to go back to 2.0.10 with 3.2.0 and check values of RegLoc, after the reported error.
But it may be a while.
Can it be cause by the constant declaration?

Title: Re: static REGLOC <error reading variable> - debug error?
Post by: Martin_fr on August 14, 2020, 11:45:09 am

Quote from: Birger52 on August 14, 2020, 11:17:12 am

Can it be cause by the constant declaration?

Probably. Though it is hard to tell if the trouble is gdb, fpc, or the fact that the dwarf spec may be to unspecific....

The constant is a member of the structure.
Now normally in debug info members have some info about where in the structures memory they are (offset to start of struct).

Only a constant is not stored in the structure. => So that field in the debug info is missing.
Dwarf3 just says "has member location". There is no "must have". Only in dwarf 5 this is clarified to be optional, but even then to be assumed zero (offset) if missing.
(Note that DW_AT_MEMBER_LOCATION is only a starting point for the fields value's address, and there can and will be further steps to calculate the address, and those steps are not bound to use the member's location)

My guess: GDB stops after not finding the location. Or it assumes it to be 0 offset, but then still can not find instructions where to read the constant. Because a constant is replicated as a literal in the debug info. So there is no memory location at all...

To me the debug info looks ok. But when implementing FpDebug from the dwarf spec, I did not foresee this case either... (So fpdebug needs fixing too).

Also you would have to test, if GDB deals with string (shortstring in this case) constants outside a structure..... I have not even checked that. (And that may depend on fpc version)

Title: Re: static REGLOC <error reading variable> - debug error?
Post by: Birger52 on August 14, 2020, 12:07:25 pm

I'm afraid I can't follow all you are saying - but appreciate the effort.

I reinstalled 2.0.10 and fpc 3.2.0
The problem still exists - but only outside the object.
Inside the object RegLoc is what it needs to be (value assigned to constant).
But outside, it gives the error, even tho RegLoc is private and not addressed from outside.
(Actually it doesn't give any error - it appears only when holding mouse over variable, when execution paused).
And values of all other variables in object are wrong.
Values are correct when inside object (reading values from registry) - but outside they are not.
Probably as you mentioned, because "something" looses track of where they are.

And here's something odd.
Same problem exists for the other TSetSet object (The one whos values the editor-form can manipulate) but this instance initially has the correct values form registry.
(Holding mouse over variables name, reports the same REGLOC-error, but vlues are correct).

Title: Re: static REGLOC <error reading variable> - debug error?
Post by: Birger52 on August 14, 2020, 12:17:13 pm

And now it gets spooky...

Changing declaration of objects contants to include type

Code: Pascal [Select][+]

    
    RegLoc : string = '\Software\SDC\Play';
    lGen : string = '\general';
    lPlay : string = '\playlist';
 

Removes the problem - that is, the reported inability to read RegLoc - but it does not make the object have the values read from registry, except inside the procedure that does the reading.

Title: Re: static REGLOC <error reading variable> - debug error?
Post by: Birger52 on August 14, 2020, 12:29:13 pm

And then - before I downgrade to previous version, that functions - I tried to change the constants to variables, that are assigned values in a constructor.
It has the same effect as defining constants with type - no reported problem reading RegLoc, but unfortunately the object does not have the value read from the registry either.
Values are simply not the same outside the object, as they are inside...

Title: Re: static REGLOC <error reading variable> - debug error?
Post by: Martin_fr on August 14, 2020, 12:57:25 pm

Quote from: Birger52 on August 14, 2020, 12:17:13 pm

And now it gets spooky...

Changing declaration of objects contants to include type
Code: Pascal [Select][+][-]

RegLoc : string = '\Software\SDC\Play';

Well that makes them pre-initialized variables.

So new they will be a pointer to the memory in your application.

Quote

And then - before I downgrade to previous version, that functions - I tried to change the constants to variables, that are assigned values in a constructor.
It has the same effect as defining constants with type - no reported problem reading RegLoc, but unfortunately the object does not have the value read from the registry either.
Values are simply not the same outside the object, as they are inside...

I haven't tested this any further yet. (You do compile with all optimization disabled? -O- )

Have you "debugln" (unit LazLogger / console output, compile with -WC ) the values that the reader sets to the object?

Does it change, if you watch a single field? e.g. "nSet.IgnoreCards"
Is that strings only, or bools also?

----
You can always try FpDebug. Just install the package LazDebuggerFp and the change the debugger in Tools > Options > Debugger.

Title: Re: static REGLOC <error reading variable> - debug error?
Post by: Birger52 on August 14, 2020, 07:29:46 pm

One more...

Turns out, in the version where things are working(2.0.8/3.0.4), values are also reported wrong by debugger/watches.
But the program must be using other values, than the ones presented when execution is paused.

Did like this.
Open the editor - this creates an object called Settings, which is a TSetSet, which reads its values from registry.
Before Closing - when clicking close button - another TSetSet is created - sSet, and read from Registry.
Same class, same code.
As nothing was changed in the editor, these two object now holds the same data.
The accompanying image shows watches - and data are obviously not the same in the two objects.
What is more, the comparisons that determines if messages are sent, are all true.

So according to values in Watch window (deubgger?) this should result in messages being sent to all other apps.
This does however not happen.
No messages are sent - SendIPCMsg() is never called.

So - even tho this LOOKS all wrong, it is actually behaving as it is supposed to (And I have tested, if I change things. If I make changes, messages are sent, as they should).

And what prompted all of this, was that in 2.0.10/3.2.0 code did NOT behave as expected.
In 2.0.8/3.0.4 it does.

Title: Re: static REGLOC <error reading variable> - debug error?
Post by: Martin_fr on August 14, 2020, 08:03:31 pm

Hard to comment on, without further info....

Very important > Optimization level 0 "NONE".
And that includes, changing package options, if this code is in a package. (Because package have their own settings)

-O1 can screw up local variables.

Ideally if I could reproduce it. (Though that does not guarantee that it can be fixed, if it is a gdb problem)
I.e. small example with only those classes, and hardcoded values.

Otherwise: Log, or "debug output" https://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Log_info_for_debug_session

One thing, I did note: "sSet: vptr$TOBJECT = 0"
That must be wrong. (Or the app has corrupted data).

That is the pointer to the VMT of the class. (i.e TClass-info). That simply cannot be nil.

Title: Re: static REGLOC <error reading variable> - debug error?
Post by: Birger52 on August 15, 2020, 12:15:26 pm

Well ... optimization was -O1 and the code is not in a package

Setting it to 0 makes no functional difference (Program still behaves as expected).
Watch window seems to give up reading values, as it can't read RegLoc - image1.
But if specific object.var are requested, it does find the values - image2 (and yes - I did change setting for HistroyRec in the editor, so the difference is correct - I did check all the objects variables, even tho they are not all shown here in Watches).

This is in 2.0.8/3.0.4 - not tested in 2.0.10/3.2.0
and it is with the constant declaration

Code: Pascal [Select][+]

    private const
      RegLoc = '\Software\SDC\myStrip';
 

It may be different if changed to initiated vars or regulars vars initiated in a create constructor.

I will consider attempting to create a simpler example.
Will be a while, tho.

Title: Re: static REGLOC <error reading variable> - debug error?
Post by: Martin_fr on August 15, 2020, 01:22:47 pm

Just to clarify:

I can reproduce the "RECLOG: error reading variable". That happens with all versions of fpc. And that part cannot be fixed, unless the GDB team fixes it. (I have not tested the 9.x serious of gdb yet).

What I can not reproduce is, where one of the ...Set has "vptr$TOBJECT = 0" => and then all other variables are trash.

Title: Re: static REGLOC <error reading variable> - debug error?
Post by: jamie on August 15, 2020, 04:38:52 pm

Would be nice to see how "nSet" in the Setform is being created ?

Following your description I am getting this feeling of you sharing an object address across several apps which can not happen.

But in any case would like to see the code frag that actually creates this Class ?

Title: Re: static REGLOC <error reading variable> - debug error?
Post by: Birger52 on August 15, 2020, 08:49:37 pm

Well - I've been experimenting some, and everything is now happening inside the form - only IPCmessages distribute changes - actually only messages of changes - actual values are read by individual apps from registry.

Originally it was in a procedure shared by all apps - but it didn't do the job all that well (Think it should, and code is essentially the same).
nSet was defined as

Code: Pascal [Select][+]

property nSet : TSetSet read Settings;

but as I have moved the comparing and message sendein to the form, it has been removed - Settings is still there, of course, but there is no reference to it for the outside.
and actually only used for comparison (Only form changes values).
(Letting the form handle it all, also simplifies sending messages - the form has it's own IPCCLient)
It was never shared between apps, but appeared in a procedure in a common unit.
I have registered no difference in values or behavior in the two ways.

as simple as possible

Code: Pascal [Select][+]

  TSettingsForm = class(TForm)
    // Controls to edit values - mostly my own creations - omitted here
    // Panel and bevels as dividers to make for a informational view
    CloseBut: TButton;
  private
    Settings : TSetSet;
    // Other values - mainly to facilitate moving the form (that is borderless) ...
  public
    // Event handlers for changing values in controls - they all change values in Settings object
    constructor Create(aOwner:TComponent); override;
    procedure SendIPCMsg(aMsg, IPCId:string);
    procedure CloseButClick(Sender: TObject);
  end;
 
var
  SettingsForm: TSettingsForm;
 
implementation
 
{$R *.lfm}
 
{ TSettingsForm }
 
constructor TSettingsForm.Create(aOwner:TComponent);
begin
  inherited;
  Settings := TSetSet.Create;
  Settings.ReadSet;
  Moving := false;
  pX := -1;
  pY := -1;
end;
 
 
procedure TSettingsForm.CloseButClick(Sender: TObject);
var
  sSet : TSetSet; // sSet is settings before they are changed - used to determine what needs to be updated
begin
  sSet := TSetSet.Create;
  sSet.ReadSet;
  Settings.WriteSet;
  if Settings.BoolChrs <> sSet.BoolChrs then begin // Alert Apps that use boolChrs
    SendIPCMsg('CHG,BChar', 'myStrip_cat');
    SendIPCMsg('CHG,BChar', 'myStrip_card');
    SendIPCMsg('CHG,BChar', 'myStrip_model');
    SendIPCMsg('CHG,BChar', 'myStrip_clip');
  end;
  if Settings.ToMetric <> sSet.ToMetric then
    SendIPCMsg('CHG,Metric', 'myStrip_model');
  if (Settings.StoreTiming <> sSet.StoreTiming) or (Settings.PlayTimerInterval <> sSet.PlayTimerInterval) then
    SendIPCMsg('CHG,Timing', 'myStrip_play');
  if (Settings.PlayAuto <> sSet.PlayAuto) or (Settings.PlayAutoInterval <> sSet.PlayAutoInterval) then
    SendIPCMsg('CHG,PlaySet', 'myStrip_play');
  if (Settings.HistoryRec <> sSet.HistoryRec) or (Settings.HistoryAnt <> sSet.HistoryAnt) then
    SendIPCMsg('CHG,HistorySet', 'myStrip_play');
{
  if (Settings.IgnoreCards <> sSet.IgnoreCards) and (Settings.IgnoreModels <> sSet.IgnoreModels) then
    saveSet := true; // => update tables in DB
  Ignore Cards and Ignore models used solely by DBupdater - and is not yet implemented.
}
  sSet.Free;
end;
 
procedure TSettingsForm.SendIPCMsg(aMsg, IPCId:string);
begin
  SettingsClient.ServerID := IPCId;
  try
    SettingsClient.Connect;
  except
  end;
  if SettingsClient.ServerRunning then begin
    SettingsClient.SendStringMessage(aMsg);
    SettingsClient.DisConnect;
  end;
end;

So sSet is created when clicking the button to close the editor - it reads the current values from registry, and compares them to the edited values in Setting (was nSet), that is created and its values initialized in the forms Create, to determine what has been changed, and what apps needs information.

The form is used Modal and is currently created and freed each time.

Code: Pascal [Select][+]

procedure EditSettings(aSender:TForm;aP:Tpoint);
var
  setForm : TSettingsForm;
begin
  SetForm := TSettingsForm.Create(aSender);
  SetForm.Left := aP.X - SetForm.Width;
  SetForm.Top := aP.Y - 25;
  SetForm.ShowModal;
  SetForm.Free;
end;
 

aP is position on screen of the button clicked to edit settings. aSender is the main form of the app editor is called from.
(Will probably at some time, have a way to ensure it is only called once, so only one app at a time can open it)

Title: Re: static REGLOC <error reading variable> - debug error?
Post by: Birger52 on August 15, 2020, 08:51:50 pm

Forgot to add an image of editor at designtime:
Here it is
;)

Title: Re: static REGLOC <error reading variable> - debug error?
Post by: jamie on August 15, 2020, 11:33:35 pm

Since you are freeing the Settings form each time this would mean the object is no longer valid outside the forms operation.

That object which is within the SettingsForm will go by by when you free the form..

Using it afterwards is going to prove to be tough..

Title: Re: static REGLOC <error reading variable> - debug error?
Post by: Birger52 on August 16, 2020, 11:59:01 am

Well - variables are only accessed when the form exists.
And the object is created with the form, every time.
So no problems.
Pretty sure that kind of faults, would result in SigSev errors.

Title: Re: static REGLOC <error reading variable> - debug error?
Post by: Martin_fr on August 18, 2020, 12:09:00 am

Quote from: Martin_fr on August 14, 2020, 11:45:09 am

To me the debug info looks ok. But when implementing FpDebug from the dwarf spec, I did not foresee this case either... (So fpdebug needs fixing too).

I extended FpDebug (in trunk). It can now correctly display such static const fields.

This applies only to "untyped constants" within a class (adv record, etc).

"typed const" (public const foo: ingeger = 1) are actually pre-initialize vars. => and for any "class var" fpc does not write member infos in the debug info. Instead it creates a global var (not part of the class / exact name depends on fpc version): _static_classname_FIELD

As for gdb:

I do think gdb is NOT at fault here.

The presence of constant data "DW_AT_const_value" in class members is not part of the dwarf spec. GDB therefore does not need to know about it. GDB can (and should) ignore this.
This however means that gdb would try to get an address at which the value is to be found. Since FPC does not provide that, it would go to the default (none in dwarf-3 / first byte in class under dwarf-5). This address obviously does not have data that fits the string type => so that goes wrong.

One could argue, that gdb should continue with further fields. But thats a matter of opinion. If one field failed to read (maybe violating memory bounds), then it could also be argued that gdb is right to stop.
I do not know the internals of gdb. I do not know if that behaviour is by accident or intended.

Title: Re: static REGLOC <error reading variable> - debug error?
Post by: Birger52 on August 19, 2020, 01:19:15 pm

I am not able to understand all you're saying - what I do understated makes sense.

The main - disturbing - thing to me, is that info in watch is not reliable.
In 2.0.10 half of the information is wrong, and the program derived from source is not functioning.
In 2.0.8 the information is also wrong, but the program actually functions.

(And there are other peculiarities with the watch - objects of class TList have no Count property for instance [well, they do, but in watch it must be addressed as objectname.FItems.FCount ims]. Many other classes have "missing" properties, that is used regularly in source - most of which I haven't found a workaround for yet. It severely limits the use of not only the watch/debug but actually Lazarus itself.)

If Lazarus is to be a reliable tool, there is no way it will be acceptable, that because it can not find a constant that makes no sense outside the object, it also can not find the variables that the object actually exists to supply.
No matter if the problem is with Lazarus, a debugger or somewhere else.

Sometimes it's like beating nails with a hammer that keeps loosing the head, and you end up spending time finding workarounds for the tools shortcomings, rather than solving the problem you set out to solve.

I'm not complaining, criticizing or placing blame.
I do understand it's not simple - and that it has probably not become simpler since I wrote my first programs back in the '80's.
Just voicing my opinion as a - not very experienced - Lazarus user.

Title: Re: static REGLOC <error reading variable> - debug error?
Post by: Martin_fr on August 19, 2020, 02:37:59 pm

Quote from: Birger52 on August 19, 2020, 01:19:15 pm

I am not able to understand all you're saying - what I do understated makes sense.

At the start of the topic there were 2 issues.
- The static field, that gave an error
- The wrong/ cut off data

For the first one, I did say at some point that debuginfo (as created by fpc) looked ok.
In my last response I retracted this.
debug-info for the static field is wrong. Hence GDB can not show "RecLoc". (But fpdebug now can, at least in Lazarus trunk)

If you add more static fields to a class ("const" or "class var"), then some will show / some not. And those that do show, may cause more problems with gdb....

The remainder of my last reply was technical details on the "RecLoc" issue. Just in case any one has an interest in checking dwarf specs themself. (So "DW_AT_const_value" is only for people who look at debugger internals)

Quote

The main - disturbing - thing to me, is that info in watch is not reliable.
In 2.0.10 half of the information is wrong, and the program derived from source is not functioning.
In 2.0.8 the information is also wrong, but the program actually functions.

For that I have not enough info to find out why.
If I could reproduce, that would be good.

Just one note: If you have linux, and can run that project on Linux: Do so

Compile with -gv (for valgrind) / Project Options > Debugger

And then outside the IDE:
valgrind --tool=memcheck ./yourapp

just to see, if there are any dangling pointer or uninitialized data issues.

-------
If you are limited to windows

Turn on all the bells and whistles (if you have not already) -CRiot -gh -gt
The -gt can be used with 1, 2, 3 or 4 "t" -gtttt / Test them all

Set the environment
HEAPTRC="keepreleased"
And see if this makes any difference.

Quote

(And there are other peculiarities with the watch - objects of class TList have no Count property for instance [well, they do, but in watch it must be addressed as objectname.FItems.FCount ims]. Many other classes have "missing" properties, that is used regularly in source - most of which I haven't found a workaround for yet. It severely limits the use of not only the watch/debug but actually Lazarus itself.)

Basically: ALL properties that have a getter function. Because the debugger can not call functions. (and because 1 or 2 more issues).
Joost is working on function calling in fpdebug. After that the other issues can be addressed.....

Quote

If Lazarus is to be a reliable tool, there is no way it will be acceptable, that because it can not find a constant that makes no sense outside the object, it also can not find the variables that the object actually exists to supply.
No matter if the problem is with Lazarus, a debugger or somewhere else.

Part of it needs to be fixed in FPC => so earliest (with a lot of luck) fpc 3.4 // with "lottery jackpot winning"-like luck, fpc 3.2.x
In Lazarus FpDebug will eventually address those issues. (Some are already addressed).

Believe it or not, the issue with "RegLoc" has never been reported, before you did. At least not to my knowlegde, and I have been looking at the debugger for more than 10 years. So I would likely know, if it had been raised.

The issue with the "bad values" in one of your objects => well, we still have to find the reason.

Btw: Did you try if FpDebug shows the values correct?

Quote

Sometimes it's like beating nails with a hammer that keeps loosing the head, and you end up spending time finding workarounds for the tools shortcomings, rather than solving the problem you set out to solve.

Try fixing/improving/writing a debugger, if the only debugger that you can use in order to debug the failing debugger, is (yes well) that failing debugger itself.... :)

Quote

I do understand it's not simple - and that it has probably not become simpler since I wrote my first programs back in the '80's.
Just voicing my opinion as a - not very experienced - Lazarus user.

I get it.

You see after 12 years on the debugger, having started out with much much less of a debugger, to me the current debugger is a true blessing of good.
But, I started with so much less. And I know so many workarounds....

If you are new, and the first use of the IDE keeps giving you: well that feature is not avail, and the next is neither, and ..... => Yeah I get.

Help testing / use fpdebug (at least for testing)
FpDebug in 2.0.10 (Windows/Linux) is quite good.
In trunk it is even better.

the fixes for RegLoc are in trunk only, because the code has changed a lot, so merging no longer works.

Title: Re: static REGLOC <error reading variable> - debug error?
Post by: Martin_fr on August 19, 2020, 02:56:48 pm

Btw: Properties and Function calling.

Yes
List.Count => would be a blessing.
List.Item

=> *probably* too

But back in my Delphi days => it turned out to be a nightmare.

One of my early experiences debugging under Delphi:
I had an app that crashed, except if I single stepped then it did not crash. So how to find a bug, if the bug disappears when you try to trace it?
It turned out it crashed because FHandle was nil.
But I had "Handle" as a watch.
And while single stepping, the debugger called "GetHandle" (the getter / which also creates it, if it is nil). So while single stepping FHandle was not nil, because the debugger fixed the bug in the code - hiding it.

Title: Re: static REGLOC <error reading variable> - debug error?
Post by: Birger52 on August 19, 2020, 06:24:49 pm

Respect and appreciation of all the hard work.

I have no Linux.
(Have tried a couple of times, with old PC's. Linux is only free, if the users time has no value - so I haven't really been able to afford it - yet anyway).

No - I had not tried fpDebug.
(Don't jinx it - or if it ain't broke, don't fix it. So when things start functioning after a lot of problems, it takes a little courage to experiment again.)

I installed "fpdebug 0.0" from the internal list in Lazarus.
(Packages menu item Install/Uninstall packages)
This is the one that comes with Lazarus 2.0.8.

It still gives the problem with RegLoc
<TSETSET> = {<TOBJECT> = {_vptr$TOBJECT = $1002d2c88}, static REGLOC = <error reading variable>
(apparently missing one } in watch window.... ;) )
But all other values in the object are reported correct!
(Optimization 0) - this in contrast to whatever debug was used before installing fpDebug.

Is there a newer version of fpDebug I should use?

Title: Re: static REGLOC <error reading variable> - debug error?
Post by: Cyrax on August 19, 2020, 07:21:37 pm

Quote from: Birger52 on August 19, 2020, 06:24:49 pm

Respect and appreciation of all the hard work.

I have no Linux.
(Have tried a couple of times, with old PC's. Linux is only free, if the users time has no value - so I haven't really been able to afford it - yet anyway).

No - I had not tried fpDebug.
(Don't jinx it - or if it ain't broke, don't fix it. So when things start functioning after a lot of problems, it takes a little courage to experiment again.)

I installed "fpdebug 0.0" from the internal list in Lazarus.
(Packages menu item Install/Uninstall packages)
This is the one that comes with Lazarus 2.0.8.

It still gives the problem with RegLoc
<TSETSET> = {<TOBJECT> = {_vptr$TOBJECT = $1002d2c88}, static REGLOC = <error reading variable>
(apparently missing one } in watch window.... ;) )
But all other values in the object are reported correct!
(Optimization 0) - this in contrast to whatever debug was used before installing fpDebug.

Is there a newer version of fpDebug I should use?

You need to get development version of Lazarus (the trunk). Use Fpcupdeluxe to acquire it : https://forum.lazarus.freepascal.org/index.php/topic,34645.0.html

Title: Re: static REGLOC <error reading variable> - debug error?
Post by: Martin_fr on August 19, 2020, 07:45:05 pm

Quote from: Birger52 on August 19, 2020, 06:24:49 pm

It still gives the problem with RegLoc
<TSETSET> = {<TOBJECT> = {_vptr$TOBJECT = $1002d2c88}, static REGLOC = <error reading variable>

As Cyrax and I said: This is only fixed in trunk.
FpDebug can only be upgraded with the entire IDE.

But if the other values show correct now, then the issue was somewhere in gdb. And unless the gdb team fixes it by chance (or have done already in a newer version) then that is not fixable for the gdb debugger.
That is one of the advantages of Fpdebug => at least if it is buggy, we can fix it.

Title: Re: static REGLOC <error reading variable> - debug error?
Post by: Birger52 on August 20, 2020, 10:46:13 am

Tried to install the "trunc" thing - no luck.
Definately needs some explanation of what it is, what it does, why it does it, and how to use it (and maybe even for what...)

First I clicked the Trunc-button.
It spins off - Window saying "not responding", using 80% CPU and 4GB Memory
Shut it down via TaskManager after around 5 minutes.
Restarted and marked 2.0.8 and 3.0.4 - with the same result.

Not going to play without this with some sort of explanation/documentation.

Log looks like this:

Quote

[2020-08-19 21:12:46.349 Info] 19-08-2020 21:12:46: fpcupdeluxe: V304 (20200722) started.
[2020-08-19 21:12:46.349 Info] FPCUPdeluxe V1.8.0e for x86_64-win64 running on Win64-6.1.7601
[2020-08-19 21:12:46.349 Info] Checking dev-libs for:
[2020-08-19 21:18:45.347 Info] 19-08-2020 21:18:45: fpcupdeluxe: V304 (20200722) started.
[2020-08-19 21:18:45.347 Info] FPCUPdeluxe V1.8.0e for x86_64-win64 running on Win64-6.1.7601
[2020-08-19 21:18:45.347 Info] Checking dev-libs for:

Title: Re: static REGLOC <error reading variable> - debug error?
Post by: Martin_fr on August 20, 2020, 02:08:51 pm

Before going about installing "trunk" (not "trunc", but I get that wrong myself too), lets talk if you really want it.

"trunk" is the developer version.
That means, that it is the least tested version. And it can (and often does) have new bugs.

That means "trunk" is not a fixed version. It is a "running" version. It changes daily. trunk means the most recent code committed.

Example:
I write some code (fix or feature). I make sure it works for me, on my machine. I usually spent a few minutes for that testing, unless its something bigger.
=> Then I add it to trunk. (So trunk changes)
Then other developers and a users that are using trunk will start using it. Some update daily, and get it right away, others may take a month...
In case my code does not work, they will report it.
Overall the bugrate is not that drastic. But you need to be aware.
I use trunk everyday, and I get a problem (introduced by someone else) maybe 2 or 3 times a year.

Normally a fix like this would be could for the "fixes branch".
Like trunk, it moves.
But it only gets a selected subset of the changes to trunk. Bugfixes only, and usually either delayed, or small enough changes to avoid most of the above bugs.
"fixes" then occasionally get a "tag" to one revision in it (one point in time) => and this becomes a release.

However I have not transferred that particular change (const members) to fixes. Because the codebase for fpdebug has changed a lot more in trunk, than in fixes. So its a lot more work to merge(transfer).
In fact in this case, I would need to write a modified fix, if I wanted to add it to fixes.

So now you need to decide how badly you want that fix.
FpDebug in 2.0.10 already solved most of your issues. Only the constant is not shown.

I can't comment of fpupdeluxe. I hear lots of good stuff, but I do not use it, since I update manually.

Title: Re: static REGLOC <error reading variable> - debug error?
Post by: Birger52 on August 23, 2020, 11:06:55 am

OK - thx for explanation.
Way too early on my learning-curve for that, I think.