Possible bug in debugger for Delphi 10.3.1

[Sherlock 663]

Just noticed this possible issue with the debugger:

I have a simple generic list. Up until 10.2 when debugging I was able to see the items in that list - drill down into them if I wished. But in 10.3.1 the debugger stops at "items", I only see the addresses, but can't view the items anymore, this is a serious break in behavior.

 

Am I missing something? Is there some setting I now have to apply to get the old behavior? Or is this a bug?

 

TIA for any insights.

[Uwe Raabe 2057]

The debugger is just doing fine here. Since 10.3 there is no FItems field anymore, so there is nothing the debugger can show. You can inspect the property List, though. Unfortunately that will not work using the hint window.

[Sherlock 663]

So it's a bug. Please don't tell me it's a feature. This has been a very nice and comfortable tool for debugging. I'll open a call.

[Uwe Raabe 2057]

20 minutes ago, Sherlock said:

So it's a bug.

No, the debugger can only show fields in a class that exist. That FItems field you see in 10.3 is not part of TList<T>, but of TListHelper and declared as 

    FItems: Pointer;

So what other than that pointer address should the debugger show here?

 

It is a complete different thing to argue about that code change in the first place, but that is out of scope here. There have already been some other issues following up this change.

 

[Sherlock 663]

OK, wait a minute, please. I am just a dumb user and not an IDE developer. Since the introduction of generics this way of inspecting the contents of an object worked just fine. Now it does not anymore. I actually don't care what "they" did and why. I have not read anything in the release notes stating any changes in the debugger (apart from debugging optimized builds), for better or worse. So from my point of view it's unintentionally broken. Plain and simple. I really hope Rudy will see this btw. in reference to the discussion about breaking changes 😄

Guessing from your arguments my call might get closed soon, but here it is anyway: https://quality.embarcadero.com/browse/RSP-24041

[Remy Lebeau 1393]

29 minutes ago, Sherlock said:

I have not read anything in the release notes stating any changes in the debugger

Because this is NOT a change in the debugger itself!  It is a change in the implementation of the class that you are trying to debug.  TWO DIFFERENT THINGS.

30 minutes ago, Sherlock said:

So from my point of view it's unintentionally broken.

Just because you can't see the data anymore doesn't mean it is "broken".  It just means the data is abstracted away and hidden from you.

[Uwe Raabe 2057]

1 hour ago, Sherlock said:

I am just a dumb user and not an IDE developer.

That has nothing to do with the IDE. It is a change in the RTL sources and the field you are trying to inspect is a Pointer, which the debugger correctly shows as a hex address.

 

Since your report suggests an error in the "Debugger, Delphi Compiler, IDE (Development Environment)" it simply targets the wrong people and will correctly be closed. There simply is no bug in the debugger, compiler or IDE in this case.

[Sherlock 663]

Thank you all for the clarifications. I'll let the girls and boys at Embarcadero decide what to do with this. It is baffling however, how you are able to dismiss blatant reduction of usability with "the code was changed". I wish I could do this to my customers.

[Stefan Glienke 2002]

They probably should fix this with a debugger visualizer that knows to interpret the FItems field in a TListHelper properly (it also has the fields FCount and FTypeInfo to be able to)

[Lars Fosdal 1792]

Debugger improvements were on the most recent roadmaps, wasn't they?

[Uwe Raabe 2057]

4 hours ago, Sherlock said:

It is baffling however, how you are able to dismiss blatant reduction of usability with "the code was changed". I wish I could do this to my customers.

Well, we don't like the code change either - not only for the lack of FItems being inspected during debugging. The point is that the debugger is not the right place to put the finger on.

 

4 hours ago, Stefan Glienke said:

They probably should fix this with a debugger visualizer that knows to interpret the FItems field in a TListHelper properly (it also has the fields FCount and FTypeInfo to be able to)

I wonder how the debugger could figure out that the fields FItems, FCount and FTypeInfo have to be merged into something like TArray<T>.

 

On the other hand: TList<T> already provides a property List which has all things necessary in one place. If the evaluation were not restricted to variables and fields only, but could be extended to properties and functions, that would have much more value than just inspecting those TList items.

[Stefan Glienke 2002]

15 minutes ago, Uwe Raabe said:

I wonder how the debugger could figure out that the fields FItems, FCount and FTypeInfo have to be merged into something like TArray<T>.

Write a visualizer for TListHelper that does not simply show all its fields the standard way but as array. Or simply call its FListObj.ToArray as evaluated expression instead (which would be the dumb version as that causes allocation every time).

Edited March 21, 2019 by Stefan Glienke

[ThorkildFriis 0]

Well, I have not been wrting code for years and I have just downloaded 10.3. It all seemed very fine indeed. Until I started debugging.....

The debugging capabilities are set back to the days before!! Delphi 3 (i.e. the second 32 bit delphi, and I still have a book from 1996 written by Marco Cantù about Delphi 3...

Eclipse has that feature, Android Studio has it, Visual Studio has it....

Delphi has had it until now.

 

It is not a new feature.

 

It is the very dead of Embarcadero RAD if they do not fix that issue in a jiffy.

 

This is by far the most brain dead feature I have ever seen. Setting back the usability of Delphi by more than 30 years in a highly competitive market. Even Mugabe couldn't come up with a more stupid plan than this, even if he did his best...