Debugger in 10.3.3 is useless :'(

[Clément 148]

Hi,

 

I just upgraded to 10.3.3 and start compiling my applications. By chance I spotted some strange things with the debugger. When I tested the debugger... well... I'm posting here before taking action !

I took some pictures to help with the context.

 

The first picture is what caught my attention. Notice the method "DoInvoke<T>" with an invalid break point ( It is perfectly valid under 10.3.2). Well, DoBuildURI is called from DoInvoke (See picture 2 when I comment out DoBuildURI). If I comment out DoBuildURI, the expected behaviour  is to remove all the lines from DoBuildURI as it is called only from DoInvoke. (Under 10.3.2 they are.)  But notice that there's still a blue dot in DoBuildURI (That's the entry point of DoInvoke<T>!!!!).

 

The third picture shows the call stack. We can clearly see that DoInvoke is called.

And the fourth picture is terrifying: In the Call Stack windows, I double click the DoInvoke and a line from DoBuildURI is highlighted! (Remember that blue dotted "end" from picture 2).

 

DoInvoke is compiled and called but is undebuggable. There are other parts in my application with the same behavior.

 

I cleared , build and compiled my project against 10.3.3 under VCL Win32, VCL Win64, FMX Win32, FMX Win64  and in a new dproj (Those pictures are from a brand new project using the same units).
The application seems to be working fine.

 

 

Just had some more info. I changed the declaration of DoInvoke from

 

      function DoInvoke<T>( const aMethodName : String; const aParams : Array of TValue) : T;

 

to

 

      function DoInvoke( const aMethodName : String; const aParams : Array of TValue) : String;

 

And now the debugger sees the method. Good Job E!

 

 

Have you seen such behavior before? Do I have to try reinstalling 10.3.3 or should I go back to 10.3.2 and wait for 10.4?
 

This is the class declaration

type
   TWebAPIClientConnector<I : IInvokable> = Class( TInterfacedObject )
   private
      fRTC : TRttiContext;
      fRttiType : TRttiType;
      fBaseRoute : String;
   private
     fConnector : I;
     function ConvertToString( const aValue : TValue ) : String;
     procedure DoExtractAttributes( const aAttributesArray : TArray<TCustomAttribute>; var aHttpMethodType, aHttpMethodRoute : String );
     function DoBuildURI( const aMethodName : String; const aParams : Array of TValue ) : String;
     function DoConvertWebAPIResponse<T>(aWebAPIResponse : TJSONValue ) : T;
   protected
      function DoInvoke<T>( const aMethodName : String; const aParams : Array of TValue) : T;
   public
      constructor Create;
   End;

 

 

Clément

Edited November 23, 2019 by Clément

[Clément 148]

Well,

 

I re-installed 10.3.3 and the problem persists. Going back to 10.3.2

[Dalija Prasnikar 1404]

15 minutes ago, Clément said:

I re-installed 10.3.3 and the problem persists. Going back to 10.3.2

This sounds similar to 

Debugger shows blue dots at wrong lines

https://quality.embarcadero.com/browse/RSP-23497

 

But I have been seeing such issues in all Rio versions. However, I could not create small reproducible test case. 

 

I have tried to simulate part of your problematic code and it works fine in 10.3.3 for me. It seems like trigger requires more complex code. 

[Clément 148]

1 minute ago, Dalija Prasnikar said:

This sounds similar to 

Debugger shows blue dots at wrong lines

https://quality.embarcadero.com/browse/RSP-23497

 

But I have been seeing such issues in all Rio versions. However, I could not create small reproducible test case. 

 

I have tried to simulate part of your problematic code and it works fine in 10.3.3 for me. It seems like trigger requires more complex code. 

Indeed,

 

The method

function DoConvertWebAPIResponse<T>(aWebAPIResponse : TJSONValue ) : T;

 

Also shows the same behavior. ( No blue dot, cannot place breakpoint, appears in the call stack and when accessed from the call stack shows a different part of the code.
When I trace into some other routines that correctly displays the blue dots, the editor shows a completely wrong line. For example, when I hit [F7] to return to DoConvertWebAPIResponse<T> (which is inaccessible ) the debugger places the editor in middle of the class constructor and the Local Variable window displays the local variables  from DoConvertWebAPIResponse.

If I remove some of the private variable declaration like for example

   private
      fRTC : TRttiContext;
      fRttiType : TRttiType;
      fBaseRoute : String;

 

The blue dot moves a little higher.

 

I'm installing 10.3.2. Let's see if it's my Delphi installation that got corrupted and I'll have to do a clear installation, or if it works under 10.3.2 then I'll know for sure something is wrong with 10.3.3.
In fact, it's very hard to duplicate. I'm not using IDE Fix pack.

 

I don't think there's a 3rd party package problem/conflict. The 10.3.3 went well. No errors. All packages were loaded during the IDE startup. I compiled most of projects without any problem. I guess I got lucky to spot this issue on that particular project

 

Clément

 

 

[Clément 148]

Just installed 10.3.2 and the same debugger behavior is happening. 

10.3.3 broke something.

Well... tomorrow I will reinstall 10.3.3 from scratch

 

[Uwe Raabe 2064]

Perhaps it helps to delete the .dsk file of the project and/or project group.

[Clément 148]

5 hours ago, Uwe Raabe said:

Perhaps it helps to delete the .dsk file of the project and/or project group.

I completely remove 10.3 (Clean all registry et al) and reinstalled it. I deleted all dsk, dcus, .local but still, no way to debug the DoInvoke. Truly disappointed.

I guess I'll have to hunt down all RAD Studio entries in my registry to be able to uninstall it properly. And one weekend is completely lost

[Dalija Prasnikar 1404]

@Clément Sometimes simply moving problematic code to the end of the unit helped. 

 

Debugging in Rio is much worse than in Tokyo.

[Clément 148]

I'm really worried.

I completely removed 10.3 using the uninstaller. Using CCleaner I remove all leftover the uninstaller left. Using registry editor I removed all entries for Rad Studio 20.0 and all 1a.0 . Reinstalled 10.3.3 using the Webinstaller (All those trials are done with Webinstaller).
Still no way to debug method with the following signature: function method<T>( const aMethodName : String; const aParams : Array of TValue) : T;

 

What's next? Going ISO installer?

 

 

Edited November 24, 2019 by Clément

[FredS 138]

15 minutes ago, Dalija Prasnikar said:

Debugging in Rio is much worse than in Tokyo.

 

And Tokyo was much worse than Berlin 🙂

[Uwe Raabe 2064]

Can you attach a small example showing the problem? Just to rule out it is somehow bound to your system only? That would also be helpful for a bug report.

[Clément 148]

2 hours ago, Uwe Raabe said:

Can you attach a small example showing the problem? Just to rule out it is somehow bound to your system only? That would also be helpful for a bug report.

The code runs in Berlin and Tokyo ( I'm not crazy, yet!  ).
Anyway, with both 10.3.2 and 10.3.3 broken I will have to use Tokyo to debug and probably release the application by Dec 15.
Under Tokyo the application is not compiling because there's some RTL diferences ( ex: enum exists in Rio but not in Tokyo). I'm fixing such glitches and as soon as I have a running system, I will work on that sample.

 

I installed both 10.3.2 and 10.3.3 twice today, from scratch. Both developed NonDebuggable Agreement

[Jacek Laskowski 57]

Maybe you're using automatic inline?

 

{$INLINE AUTO}

 

from docs:

 

"Behaves like {$INLINE ON}, with the addition that routines not marked with inline will be inlined if their code size is less than or equal to 32 bytes."

[Sherlock 663]

Just a reminder for the next time anyone installs a Delphi update: TAKE A SNAPSHOT OF THE VM.

And if you don't use a VM...reconsider and then just use one from now on. The hassle is reduced to a minimum.

 

 

[Lars Fosdal 1793]

VirtualBox is really nice for making test VMs for Windows and Linux.

Install your favorite Windows version in a clean VM.
Hotfix it and adapt it to your liking.

Clone it.  Install 10.3.2.  Snapshot it.

Clone the original again. Install 10.3.3.  Snapshot it.

Voila! Side by side comparison is now possible. 

[Yaron 53]

I'm getting a new issue with the debugger, it's reproducible for me every time (in a specific bit of code in a larger project) and freezes the IDE with the "Local Variables" pane flickering like crazy until I terminate the process.

 

1. I Call this function "PrepareURL('mailto:bla@bla.org',URLTypeEMail)" (see below).

2. Place a breakpoint before the case in the function below.

3. Open the "Evaluate/Modify window" and type in "sURL".

4. Change the value of sURL from "mailto:bla@bla.org" to "bla@bla.org".

5. IDE freaks out.
 

function  PrepareURL(sURL : String; sURLType : Integer) : String;
begin
  Case sURLType of
    URLTypeWebSite : If Pos('://',sURL)                = 0 then Result := 'https://'+sURL else Result := sURL;
    URLTypeEMail   : If Pos('mailto:',Lowercase(sURL)) = 0 then Result := 'mailto:'+sURL  else Result := sURL;
    URLTypePhone   : If Pos('tel:',Lowercase(sURL))    = 0 then Result := 'tel:'+sURL     else Result := sURL;
    else Result := '';
  End;
end;

However, it doesn't happen in a clean project, something else is involved too and I'm not sure what.

[FredS 138]

57 minutes ago, Sherlock said:

VM...reconsider

Or don't install EMB anything 'till your daily backup ran then recovery is a click away 🙂

 

[Attila Kovacs 631]

5 hours ago, Sherlock said:

reconsider and then just use one

I tried VB and it was too slow for me. How do you come over that everything lags? 

[Clément 148]

I don't think VM would work for me as I find myself running at least 2 instances of delphi. I don't think my machine can cope with host and VMs. 

 

Anyway, goodnews!

I manage to isolate the problem in a small sample. Tonight I will do some more testing and I will attach the example. 

With that small sample, hopefully, you will be able to duplicate that behavior in your setup.

 

I decided to keep 10.3.3. I will need less time modifying this code to something "debuggable" than making my project runs against Tokyo or Berlin. Most of my testing is automated, but some of those test are not compiling either under tokyo or berlin. I don't want to mess with my testing routines and with my already working code.
So I will keep my current setup, and find a way around this "bug". Who's to say I would be in multi thread task without using sleep 😂

 

 

[aehimself 399]

6 hours ago, Lars Fosdal said:

Snapshot it. [...] Snapshot it.

Please tell me that Oracle VirtualBox is not using incremental/differential snapshots (like VMware does)! If yes, creating a snapshot and continuing to use the VM will eat up your disk space quicker than you could say "upgrade"!

[Clément 148]

Here is a small example duplicating the exact same behavior of my main project

 

procedure TForm1.FormCreate(Sender: TObject);
begin
  fSomeConnector :=  TSomeConnectorCls.Create;
  caption := Format('Result= %d',[fSomeConnector.A1]);  // Place a breakpoint here
end;

 

the IDE go to uSomeConnectorCls (line 22) :

 

function TSomeConnectorCls.A1: Integer;
begin
 Result := DoInvoke<Integer>('A1',[1,2]);  // Press [F7] here
end;

 

Watch as the debugger completely ignores DoInvoke<T> and goes straight to DoBuildURI.

 

 

Proceed with [F7] until DoBuildURI ends... and watch as the IDE goes back to the main form.

The result is 11 so DoInvoke is called and executed to the last instruction!

 

 

I wasn't able to duplicate the invalid entry point at the end of DoBuildURI when comment out of DoInvoke<T> though

 

Undebuggable.zip

[Lars Fosdal 1793]

 

 

 

 

2

10 hours ago, Clément said:

I don't think VM would work for me as I find myself running at least 2 instances of delphi. I don't think my machine can cope with host and VMs. 

 

You can pause the VMs so that they use zero CPU. Unpausing is near instant.  They will still use memory, though.

[Stefan Glienke 2019]

10 hours ago, Clément said:

Here is a small example duplicating the exact same behavior of my main project

I just tested it and reduced the code further to pinpoint the wrong behavior, added additional information and reported as RSP-27000

[Yaron 53]

13 minutes ago, Stefan Glienke said:

I just tested it and reduced the code further to pinpoint the wrong behavior, added additional information and reported as RSP-27000

I'm also experiencing this issue, at first I thought it was the issue where unicode characters entered the code by a copy & paste operation (which in the past lead to cases where the debug/code got desynched by a few lines).  However, I did my usual fix for that issue (Copy/paste/convert to ascii), but it didn't work this time.

 

The strange thing for me is that this de-sync starts to happens BEFORE any actual functional code and the increases further down the code, check out the included screenshot.

[Stefan Glienke 2019]

If there are no generics it's a different issue than RSP-27000.