Daniel 417 Posted March 5, 2021 Not sure if we have a confused debugger, but for sure we do have a confused developer. Take the following code: procedure TForm1.Button1Click(Sender: TObject); var i ,j : integer; begin for i:= 0 to 1 do for j:= 1 to 2 do if i+j > 1000 then ShowMessage( 'Möp!' ); end; Just run the code and see that no message appears on the screen. Now set a breakpoint on the line with the "ShowMessage"-statement. Run the code again the see that the breakpoint will be triggered and the programs stops. Now place a "begin" and an "end" around the "ShowMessage"-statement - run the code again, the breakpoint will not be triggered anymore. for i:= 0 to 1 do for j:= 1 to 2 do if i+j > 1000 then begin ShowMessage( 'Möp!' ); // < breakpoint still here end; What is going on here? For me it looks like it has something to do with the loops, as the following breakpoint is (as expected) also not triggered: j := Random(10); if j > 1000 then ShowMessage( 'Meep' ); // <-- set breakpoint here (will not be triggered) Share this post Link to post
Attila Kovacs 629 Posted March 5, 2021 (edited) wow, strange codegen, de debugger/debuginfo and the pas are out of sync Edited March 5, 2021 by Attila Kovacs Share this post Link to post
Rollo62 536 Posted March 5, 2021 (edited) The irrational "Confused debugger" cases seems to move on, its now the third one in short time with Rx1042. Definitively worth to look deeper into it. Maybe we have to wait until patch 1 is online ? Edited March 5, 2021 by Rollo62 1 Share this post Link to post
Daniel 417 Posted March 5, 2021 The original cry for help reached me from a developer using 10.3.x - so this is not limited to 10.4.2. Share this post Link to post
Rollo62 536 Posted March 5, 2021 (edited) Maybe its just an optimizing issue ? for i:= 0 to 1 do for j:= 1 to 2 do if i+j > 1000 then //<== This can never be reached, or am I wrong ? Edited March 5, 2021 by Rollo62 Share this post Link to post
Anders Melander 1782 Posted March 5, 2021 Just now, Rollo62 said: Maybe its just an optimizing issue ? You wish. The Delphi compiler doesn't optimize at that level. 1 1 Share this post Link to post
Daniel 417 Posted March 5, 2021 Good catch - but the is a reduced code-sample. Same situation still applies when comparing values from an array with values that are generated at runtime. Share this post Link to post
Attila Kovacs 629 Posted March 5, 2021 20 minutes ago, Daniel said: so this is not limited to 10.4.2. No, in berlin the same. The loop is converted to a repeat until and the debug info does not follow this transition. Share this post Link to post
Guest Posted March 5, 2021 here, on RAD 10.3.3 Arch and RAD 2010 same resulted: in Debug mode, the cursor stop on "ShowMessage" as above, but dont executed!!! hug Share this post Link to post
Stefan Glienke 2002 Posted March 7, 2021 (edited) If you look into the debugger you see what causes the breakpoint to stop It looks to me as the many situations where the compiler produces debug symbols that are a little off - as you can see in the asm view you have two different pieces being affected by the breakpoint. The thing is that every line generated by the compiler - even the implicit for the looping goes somewhere in terms of what line of code they belong to - and in this case its the piece of code happening for the outer loop. We had another situation where this happened just recently: Edited March 7, 2021 by Stefan Glienke Share this post Link to post
mario.arosio@gmail.com 0 Posted April 20, 2022 I had the same issue a few times, during the last 10 years. Everytime the solution was the same: CUT the whole text, PASTE it on notepad, then cut and paste back on Delphi IDE. This workaround worked for me because there was some tricky char in the text, or maybe there is something incorrect out of nowhere. Share this post Link to post