Recent

Author Topic: static REGLOC <error reading variable> - debug error?  (Read 3302 times)

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 6601
  • Debugger - SynEdit - and more
    • wiki
Re: static REGLOC <error reading variable> - debug error?
« Reply #15 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.

jamie

  • Hero Member
  • *****
  • Posts: 3518
Re: static REGLOC <error reading variable> - debug error?
« Reply #16 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 ?
The only true wisdom is knowing you know nothing

Birger52

  • Sr. Member
  • ****
  • Posts: 270
Re: static REGLOC <error reading variable> - debug error?
« Reply #17 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][+][-]
  1. 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][+][-]
  1.   TSettingsForm = class(TForm)
  2.     // Controls to edit values - mostly my own creations - omitted here
  3.     // Panel and bevels as dividers to make for a informational view
  4.     CloseBut: TButton;
  5.   private
  6.     Settings : TSetSet;
  7.     // Other values - mainly to facilitate moving the form (that is borderless) ...
  8.   public
  9.     // Event handlers for changing values in controls - they all change values in Settings object
  10.     constructor Create(aOwner:TComponent); override;
  11.     procedure SendIPCMsg(aMsg, IPCId:string);
  12.     procedure CloseButClick(Sender: TObject);
  13.   end;
  14.  
  15. var
  16.   SettingsForm: TSettingsForm;
  17.  
  18. implementation
  19.  
  20. {$R *.lfm}
  21.  
  22. { TSettingsForm }
  23.  
  24. constructor TSettingsForm.Create(aOwner:TComponent);
  25. begin
  26.   inherited;
  27.   Settings := TSetSet.Create;
  28.   Settings.ReadSet;
  29.   Moving := false;
  30.   pX := -1;
  31.   pY := -1;
  32. end;
  33.  
  34.  
  35. procedure TSettingsForm.CloseButClick(Sender: TObject);
  36. var
  37.   sSet : TSetSet; // sSet is settings before they are changed - used to determine what needs to be updated
  38. begin
  39.   sSet := TSetSet.Create;
  40.   sSet.ReadSet;
  41.   Settings.WriteSet;
  42.   if Settings.BoolChrs <> sSet.BoolChrs then begin // Alert Apps that use boolChrs
  43.     SendIPCMsg('CHG,BChar', 'myStrip_cat');
  44.     SendIPCMsg('CHG,BChar', 'myStrip_card');
  45.     SendIPCMsg('CHG,BChar', 'myStrip_model');
  46.     SendIPCMsg('CHG,BChar', 'myStrip_clip');
  47.   end;
  48.   if Settings.ToMetric <> sSet.ToMetric then
  49.     SendIPCMsg('CHG,Metric', 'myStrip_model');
  50.   if (Settings.StoreTiming <> sSet.StoreTiming) or (Settings.PlayTimerInterval <> sSet.PlayTimerInterval) then
  51.     SendIPCMsg('CHG,Timing', 'myStrip_play');
  52.   if (Settings.PlayAuto <> sSet.PlayAuto) or (Settings.PlayAutoInterval <> sSet.PlayAutoInterval) then
  53.     SendIPCMsg('CHG,PlaySet', 'myStrip_play');
  54.   if (Settings.HistoryRec <> sSet.HistoryRec) or (Settings.HistoryAnt <> sSet.HistoryAnt) then
  55.     SendIPCMsg('CHG,HistorySet', 'myStrip_play');
  56. {
  57.   if (Settings.IgnoreCards <> sSet.IgnoreCards) and (Settings.IgnoreModels <> sSet.IgnoreModels) then
  58.     saveSet := true; // => update tables in DB
  59.   Ignore Cards and Ignore models used solely by DBupdater - and is not yet implemented.
  60. }
  61.   sSet.Free;
  62. end;
  63.  
  64. procedure TSettingsForm.SendIPCMsg(aMsg, IPCId:string);
  65. begin
  66.   SettingsClient.ServerID := IPCId;
  67.   try
  68.     SettingsClient.Connect;
  69.   except
  70.   end;
  71.   if SettingsClient.ServerRunning then begin
  72.     SettingsClient.SendStringMessage(aMsg);
  73.     SettingsClient.DisConnect;
  74.   end;
  75. 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][+][-]
  1. procedure EditSettings(aSender:TForm;aP:Tpoint);
  2. var
  3.   setForm : TSettingsForm;
  4. begin
  5.   SetForm := TSettingsForm.Create(aSender);
  6.   SetForm.Left := aP.X - SetForm.Width;
  7.   SetForm.Top := aP.Y - 25;
  8.   SetForm.ShowModal;
  9.   SetForm.Free;
  10. end;
  11.  
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)
Lazarus 2.0.8 FPC 3.0.4
Win7 64bit
Playing and learning - strictly for my own pleasure.

Birger52

  • Sr. Member
  • ****
  • Posts: 270
Re: static REGLOC <error reading variable> - debug error?
« Reply #18 on: August 15, 2020, 08:51:50 pm »
Forgot to add an image of editor at designtime:
Here it is
;)
Lazarus 2.0.8 FPC 3.0.4
Win7 64bit
Playing and learning - strictly for my own pleasure.

jamie

  • Hero Member
  • *****
  • Posts: 3518
Re: static REGLOC <error reading variable> - debug error?
« Reply #19 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..
The only true wisdom is knowing you know nothing

Birger52

  • Sr. Member
  • ****
  • Posts: 270
Re: static REGLOC <error reading variable> - debug error?
« Reply #20 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.
Lazarus 2.0.8 FPC 3.0.4
Win7 64bit
Playing and learning - strictly for my own pleasure.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 6601
  • Debugger - SynEdit - and more
    • wiki
Re: static REGLOC <error reading variable> - debug error?
« Reply #21 on: August 18, 2020, 12:09:00 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.

Birger52

  • Sr. Member
  • ****
  • Posts: 270
Re: static REGLOC <error reading variable> - debug error?
« Reply #22 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.
Lazarus 2.0.8 FPC 3.0.4
Win7 64bit
Playing and learning - strictly for my own pleasure.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 6601
  • Debugger - SynEdit - and more
    • wiki
Re: static REGLOC <error reading variable> - debug error?
« Reply #23 on: August 19, 2020, 02:37:59 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.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 6601
  • Debugger - SynEdit - and more
    • wiki
Re: static REGLOC <error reading variable> - debug error?
« Reply #24 on: August 19, 2020, 02:56:48 pm »
Btw: Properties and Function calling.

Yes
List.Count => would be a blessing.
List.Item[x] => *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.



Birger52

  • Sr. Member
  • ****
  • Posts: 270
Re: static REGLOC <error reading variable> - debug error?
« Reply #25 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?
Lazarus 2.0.8 FPC 3.0.4
Win7 64bit
Playing and learning - strictly for my own pleasure.

Cyrax

  • Hero Member
  • *****
  • Posts: 832
Re: static REGLOC <error reading variable> - debug error?
« Reply #26 on: August 19, 2020, 07:21:37 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

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 6601
  • Debugger - SynEdit - and more
    • wiki
Re: static REGLOC <error reading variable> - debug error?
« Reply #27 on: August 19, 2020, 07:45:05 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.

Birger52

  • Sr. Member
  • ****
  • Posts: 270
Re: static REGLOC <error reading variable> - debug error?
« Reply #28 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:
« Last Edit: August 20, 2020, 10:50:01 am by Birger52 »
Lazarus 2.0.8 FPC 3.0.4
Win7 64bit
Playing and learning - strictly for my own pleasure.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 6601
  • Debugger - SynEdit - and more
    • wiki
Re: static REGLOC <error reading variable> - debug error?
« Reply #29 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.


 

TinyPortal © 2005-2018