FpDebug Watches window feature request

[440bx]

Hello,

It would be very nice if the "Page size" value was limited to something reasonable, for instance 100 because if a large number is mistakenly typed in the page size field, it causes Lazarus to spend quite a bit of time to populate the (unreasonably large) page.

Refer to the attached screenshot.  The value 985 was supposed to be in the "index box" not the "page size" box.  This caused Lazarus to spend close to 2 minutes to make a 985 element page which is rarely if ever practical.

small detail but, it would be nice to have that protection because some lists may be hundreds of thousands of items and mistakenly typing a number that large in the page size field would likely require terminating Lazarus.

Comments welcome.

[Martin_fr]

I can see the problem. Especially with an array of "some structure or composed value".

Fetching a thousand integer would be faster. And then one could want them on one page to scroll through them.

Also I want to add search/filters. (like in the inspect window). And that only works with values that have been loaded for display.


More important is the ability to abort. The values are already loaded in a thread (with fpdebug). So, if the number was decreased while they are still loading, then they should be stopped. (they aren't yet).

[440bx]

Hello Martin,

Since I have an attachment in the first post, I'm going to use it to state another "wish" about the Watches window.

When FpDebug encounters a DebugBreak() in the code, it breaks as it should and, "closes"/collapses all the lists and records that have been expanded.  e.g, in the previous snapshot, the AddressMap record is "closed" (the fields are no longer shown) and the AddressMap^.AM_INFO array is also "closed" (the elements are no longer shown.)  It would be really nice if it didn't close/collapse the records and lists, i.e, ideally, upon hitting a breakpoint, the view (fields/records/lists shown) would not change in the watches window (of course, their values would/should change as required but not the layout of the view)

I hope the above is understandable. 

Thank you.

[Martin_fr]

It should only collapse entries, if the sub items don't exist at the current location. e.g if you had "c" as structure, but now it something else...

I think it should even stay open if the fields (field names) change.
It may collapse if an array isn't long enough any more... Not sure.

That is based on the top stack frame. (as that will be active when you enter pause)

E.g.
* if I am in a method of TForm1 and have "self" expanded, and I step through the code, then it stays expanded.
* The same, if within the expanded "self" I have further expanded subwatches (like FFormHandlers, or FIcon)
* I've also tried with an "array of TForm1"

If it collapse for you, even though the values are there, then I need a bug report with an example to reproduce.


If you mean, they collapse because there is no data at the current location, but you would either
- like them to show "error" on each line (which won't work for an array, because it needs at least the length)
- re-expand when data becomes available (continue run/step OR changing stack frame)

In that case please add a feature request (because my list is filling up, and I can't keep all the forum threads open as reminder)

As for the feature part. That may be a while, it probably will have to wait until I solve the entire "how to store the metadata / like display-format".

E.g., currently locals don't have individual display formats, because they come and go all the time (stepping into changes the list, etc, but internally even just stepping recreates the list). If the list is changed/ recreated, then currently that looses all the metadata...

That affects at least the ability to restore "expanded" for nested items. Because currently that state is stored on an item that might have been deleted.

[Martin_fr]

Also keep in mind if you want

If you mean, they collapse because there is no data at the current location, but you would either
- like them to show "error" on each line (which won't work for an array, because it needs at least the length)

That causes an other issue.

Let's say "foo" is an array. And expanded. And if the array wasn't there, the IDE would even remember the last "length" so it could show "dummy error entries".

However any of the following could happen.

==> You step into something, that has a variable of the same name "foo", but different data.


* The array had the entries 100..110 shown. But it now (temporary) shrinks to 20 entries.  Then it may no make sense to show error entries for 100..110.
And if "bounds are enforced" then that is not possible. (There is another topic on that)

* It was an array of structures in the caller, and now is an array of integer (or an array of array).
Then what about nested entries that used to be expanded?
- If the new array is "of integer" there is no expanded state.  There is no way to have an integer expanded with dummy error entries.
  Even restoring such expanding states later is tricky, because even if later there is an array that could expand those sub-items, it may not be the same as before.
- If the array changed to an "array of array" should it then keep the sub-arrays expanded, to match which sub-structure were expanded before?


* Similar, if "foo" is an array in the caller, but a structure in the callee => keep it expanded? (not sure it currently may even do that).
But it certainly becomes tricky which sub-items to re-expand when it changes back to an array (step out). Even if the previous set of indexes was remembered, is it still applicable, did the step out return to the array  to which that applied (instead of step out, it could be "run to break")


I have to solve some of that anyway for locals... I have to see where I end up with that.

[440bx]

The conditions you mentioned that would cause the records or arrays to collapse are not taking place in the program where I'm having the problem.  The only change is that elements have been added to the array, the views have not changed yet the records and the arrays are collapsed every time a DebugBreak() is encountered.

I figured I'd write a small sample program to demonstrate the problem but, to my dismay, the problem does not occur in the sample program.

At this time, I don't know why the behavior is different between the two. 

Anyway, just FYI, be aware that under certain conditions (which I don't know what they are) records and arrays are collapsed when FpDebug executes a DebugBreak()

If I figure out what in the code is causing that, I'll make it a point to post it here and, if possible, replicate the problem in a small program.

[Martin_fr]

I had an idea what might be happening... Though if it is this, then not sure how much can be done...
Also, from you picture I am not sure if it applies...

Maybe your data moves. E.g. an Entry is removed, and index 3 becomes index 2 and so on.
The IDE does not go by the data, but by the Index.

In an example

Code: Pascal  [Select][+][-]

1. type xyz = array of
2.   record
3.     foo: array of integer;
4.   end;

Code: Pascal  [Select][+][-]

1. SetLength(xyz, 10);
2. SetLength(xyz[3].foo, 5);
3. SetLength(xyz[4].foo, 0);

- If xyz[3].foo is expanded
- your code deletes xyz[2] => so everything bubbles up
- then the new xyz[3].foo has a length of zero, and can not be expanded.

[440bx]

I don't know what's causing it but, to give you an idea, if I put a normal breakpoint (F5) on the line that reads

Code: Pascal  [Select][+][-]

1. if IsDebuggerPresent() then DebugBreak();

everything in the Watches window is as it should be when the "normal" breakpoint is reached (as it was before the breakpoint, i.e, not collapsed), but the moment I step that "if" statement everything in the Watches window collapses.

Obviously nothing happened to the data or the structures in between.

The other problem is that I have no idea why it's doing that and the small program I wrote to show the problem, doesn't have the problem.  I'll have to figure something out to provide a "practical" example.  The program I am writing that has the problem is a little over 10,000 lines and, since it is "work in progress", the code is a mess.

[Martin_fr]

and if you directly place an "int 3" then it may also work.

DebugBreak is a function call. It stops in the function in the kernel. So you code is not the top of the callstack.
And your variables are not defined in the kernel, so they close (because they are not a structure at that point).

There are 2 issues here.
1) Ability to restore the expand in certain cases.
2) Debug break could auto adjust the stack to the caller.

The 2nd also falls into the "asm window opens" area. Only in that case, the debugger currently believes you did set a breakpoint (as in user-set breakpoint) in that asm code, and then if you decided it should stop in asm, then the asm window would be correct to pop up.

[Martin_fr]

The good thing is you are using the debugger in a very different way from what I do. So at least I get to know other use cases.

So please report the debugbreak stack issue on the bug tracker (imho as feature request).

The expand-restore.... that is somewhere on one of my lists.

[440bx]

Since  you mentioned "asm int 3" I figured I'd give that a try since there shouldn't be any stack frame issues with that method.

Please, refer to the screenshots.

The first screenshot shows I replaced the "DebugBreak()" with "asm int 3 end;"  that got me an access violation message box.

The second screenshot shows the assembly window after dismissing the message box.   What's notable is the instruction at line 5384, that "add edx, etc..." makes no sense.   

When I replaced  "int 3" with "int3" then it worked correctly and the bytes shown in the assembler window make sense (a $CC)

Apparently something goes wrong some place when the "int 3" 2-byte form is used.  Just FYI, using "int 3" (the two byte form) works fine using GDB.

For now I'll use the "int3" form since that seems to work fine.

So please report the debugbreak stack issue on the bug tracker (imho as feature request).

I'm not sure how to word the request.  I would definitely welcome any suggestion(s) you may have.

ETA:

Added the forgotten screenshots

[Martin_fr]

Sorry my fault for "int 3" vis "int3".

Not sure, but it may even already be reported.

[Martin_fr]

So please report the debugbreak stack issue on the bug tracker (imho as feature request).

I'm not sure how to word the request.  I would definitely welcome any suggestion(s) you may have.

Make a feature request that the debugger automatically selects the calling stack when it stops in kernel debugbreak.

similar as it does for exceptions/asserts