Lazarus 3.9.9 Variable Watches Fail (But Debugger Tooltips Work!) lazarus / 12-Debugger ---------------------------------------------------------------------- msintle · 2023-12-03 18:04 I'm running on the FPCUPDELUXE installed version of Lazarus trunk on Free Pascal 3.3.1. The variable watches window, I've noticed, hasn't really been working for a while. However, the debugger tooltips work (if I hover my mouse over the variable name in the code editor, the value is correctly shown). Any thoughts? ---------------------------------------------------------------------- Martin_fr · 2023-12-03 20:27 Really need an example to reproduce. Any kind of variable, specific ones? What settings? ---------------------------------------------------------------------- msintle · 2023-12-05 16:43 Any kind of variable really, just step through more than one line of code and see. I'm not aware of any particular variable watch settings, so they should all be default. ---------------------------------------------------------------------- Martin_fr · 2023-12-05 19:38 With settings I meant: debug setting in the project, and in Tools > Options In Tools > Options: what is your debugger backend? Project > Options - "type of debug info" ? dwarf .... - optimization? - smart linking? What OS? 64/32 bit ? It is strange though... For a variable like "TFoo: TMyClass" you can have different settings between tooltip and watches. But for "i: Integer" there should not be a difference at all (ok, you can go into watches properties, and set it to be hexadecimal, but I hope you would have noticed if you did / and even if, that should still not make a difference). I am mostly using Lazarus 3.99 with Fpc 2.2.3 And there it works fine. (And I debug a lot) It is possible that Fpc 3.3.1 made changes. Though I just recently run the debugger testcase, and it runs almost 20000 different watches => and it worked for 3.3.1 I did just to a quick test with 3.3.1 (updated today) and the watch window works fine (form1 and various field of the form) ---------------------------------------------------------------------- Martin_fr · 2023-12-05 19:40 Quote from: msintle on December 03, 2023, 07:04:20 pmThe variable watches window, I've noticed, hasn't really been working for a while. What exactly is "hasn't been working"? I just realized, I may be wrong in assuming that it shows the watches with some "error" in the value column? But if it does, then what is the error message? ---------------------------------------------------------------------- Martin_fr · 2023-12-05 19:48 Quote from: Martin_fr on December 05, 2023, 08:38:16 pmIt is possible that Fpc 3.3.1 made changes. Though I just recently run the debugger testcase, and it runs almost 20000 different watches => and it worked for 3.3.1 I did just to a quick test with 3.3.1 (updated today) and the watch window works fine (form1 and various field of the form) Just to say, that refers to the target app (the app being run under the debugger) having been build with fpc 331. The IDE used to debug (or the testcase) have been build with 223 ---------------------------------------------------------------------- msintle · 2023-12-06 14:12 I regret the delay in getting back to you! Quote from: Martin_fr on December 05, 2023, 08:38:16 pmWith settings I meant: debug setting in the project, and in Tools > Options In Tools > Options: what is your debugger backend? Oh of course, I should have known. LLDB (the only debugger that works on recent macOS releases), dwarf 2 (-gw2), optimization level 1 (and remember, the issue can't be related to the optimizations, since the tooltips work - just the watch window doesn't). Quote from: Martin_fr on December 05, 2023, 08:38:16 pmProject > Options - "type of debug info" ? dwarf .... - optimization? - smart linking? What OS? 64/32 bit ? macOS Sonoma 14.1.2 (ARM), unit style is not smart linkable (was that the question?) Quote from: Martin_fr on December 05, 2023, 08:38:16 pm It is strange though... For a variable like "TFoo: TMyClass" you can have different settings between tooltip and watches. But for "i: Integer" there should not be a difference at all (ok, you can go into watches properties, and set it to be hexadecimal, but I hope you would have noticed if you did / and even if, that should still not make a difference). I am mostly using Lazarus 3.99 with Fpc 2.2.3 And there it works fine. (And I debug a lot) It is possible that Fpc 3.3.1 made changes. Though I just recently run the debugger testcase, and it runs almost 20000 different watches => and it worked for 3.3.1 I did just to a quick test with 3.3.1 (updated today) and the watch window works fine (form1 and various field of the form) That's truly odd indeed. I have trouble with just simple string and integer variables. It's very odd that it works in tooltips and not the window. ---------------------------------------------------------------------- msintle · 2023-12-06 14:16 Quote from: Martin_fr on December 05, 2023, 08:40:18 pmQuote from: msintle on December 03, 2023, 07:04:20 pmThe variable watches window, I've noticed, hasn't really been working for a while. What exactly is "hasn't been working"? I just realized, I may be wrong in assuming that it shows the watches with some "error" in the value column? But if it does, then what is the error message? Thank you for the opportunity to clarify. The value field just says . This is just an ordinary string variable, in scope, recently assigned, working in the editor tooltip. ---------------------------------------------------------------------- msintle · 2023-12-06 14:18 Quote from: Martin_fr on December 05, 2023, 08:48:26 pmQuote from: Martin_fr on December 05, 2023, 08:38:16 pmIt is possible that Fpc 3.3.1 made changes. Though I just recently run the debugger testcase, and it runs almost 20000 different watches => and it worked for 3.3.1 I did just to a quick test with 3.3.1 (updated today) and the watch window works fine (form1 and various field of the form) Just to say, that refers to the target app (the app being run under the debugger) having been build with fpc 331. The IDE used to debug (or the testcase) have been build with 223 In my case the whole stack has been built with FPCUPDELUXE so I'm not sure what the version of the IDE is beyond 3.99 trunk and FPC 331. However I haven't recently updated my FPCUPDELUXE installation - was installing a new Mac yesterday, and in fact the resulting Lazarus IDE cannot even rename form components, without breaking. So my trunk is clearly a trunk older than the current trunk, as that works at least. ---------------------------------------------------------------------- Martin_fr · 2023-12-06 14:19 QuoteLLDB (the only debugger that works on recent macOS releases), "LLDB (alpha)" or "LLDB (with fpdebug)"? ---------------------------------------------------------------------- Martin_fr · 2023-12-06 14:27 Also not sure if relevant, but: - params listed in the stackwindow - ok or not? - locals window? ---------------------------------------------------------------------- Martin_fr · 2023-12-06 14:55 QuotemacOS Sonoma 14.1.2 (ARM) This is gonna make it tricky. I don't have that myself for testing (I do lldb related tests under linux, but with X86). Worst case, I can access an M2 remotely. But I try to avoid that at all cost (Being used to non-Mac keyboard and mouse behaviour, and that means a Mac never does what I want it to do ). It also means, that debugging on Mac is the least tested. It only gets the testing by users (and the Lazarus team members that use Mac). But on explicit testing (due to limits in lldb I can't even run my automated tests). But non of that should cause such a difference. "invalid" is a specific error.  But it still could be caused in too many places. (Originally it was set when the debugger was not paused, but now it is also set if no data was returned (for unknown reasons, i.e. no other error was set). So it could have a few reasons. ---- (In case of "lldb with fpdebug) there are actually some differences between watch and hint. Mainly how the result is internally stored. It seems quite strange that any type of data should trigger a failure to store the result for watches.... Just to make sure: Can you compile you IDE with -O- Menu: tools (preferences on MAC???) > configure build Lazarus Then in custom options -O- and select "make clean" radio box then press build, and restart the IDE. Actually, when you rebuild, please also add to the custom options Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i -O--Sa  -dDBG_VERBOSE -dDBG_WARNINGS -dDBG_ERRORS -dDBG_STATE -dDBG_EVENTS -dDBGMI_QUEUE_DEBUG -dDBG_FPDEBUG_VERBOSE -dFPDBG_COMMANDS -dFPDBG_THREADS -dFPDBG_QUEUE-dDBG_DATA_MONITORS-dFPDBG_DWARF_ERRORS- dDBG_THREAD_AND_FRAME  And then, if it still happens run Lazarus with --debug-log=somefile.txt and submit that file. ---------------------------------------------------------------------- msintle · 2023-12-07 15:31 Quote from: Martin_fr on December 06, 2023, 03:19:49 pmQuoteLLDB (the only debugger that works on recent macOS releases), "LLDB (alpha)" or "LLDB (with fpdebug)"? I always use beta, but in this case one alpha setting had slipped through. Makes no difference, however. ---------------------------------------------------------------------- msintle · 2023-12-07 16:15 Quote from: Martin_fr on December 06, 2023, 03:27:17 pmAlso not sure if relevant, but: - params listed in the stackwindow - ok or not? - locals window? Local window - very interesting! The first time opening it, everything shows beautifully. Step through one line of code, and the entire window loses its entire contents (just the column headers, with a gray empty region below). Stack window - seems fine and unaffected. ---------------------------------------------------------------------- msintle · 2023-12-07 16:20 Quote from: Martin_fr on December 06, 2023, 03:55:01 pmQuotemacOS Sonoma 14.1.2 (ARM) This is gonna make it tricky. I don't have that myself for testing (I do lldb related tests under linux, but with X86). Worst case, I can access an M2 remotely. But I try to avoid that at all cost (Being used to non-Mac keyboard and mouse behaviour, and that means a Mac never does what I want it to do ). It also means, that debugging on Mac is the least tested. It only gets the testing by users (and the Lazarus team members that use Mac). But on explicit testing (due to limits in lldb I can't even run my automated tests). But non of that should cause such a difference. "invalid" is a specific error.  But it still could be caused in too many places. (Originally it was set when the debugger was not paused, but now it is also set if no data was returned (for unknown reasons, i.e. no other error was set). So it could have a few reasons. Please check your PM. ---------------------------------------------------------------------- Martin_fr · 2023-12-07 17:22 Quote from: msintle on December 07, 2023, 05:15:57 pmStep through one line of code, and the entire window loses its entire contents (just the column headers, with a gray empty region below). So that could be debugger, or GUI.... The first question at this time is, if the problem is - the target (the project being debugged) is build with FPC 3.3.1 - the IDE itself being build with FPC 3.3.1 FPC 3.3.1 has a lot of new code and changes. It is possible that it does not translate the sources correctly. E.g. even fpc 3.2.2 has bugs, and one of them means that fpdebug build for 64bit X86 for Windows with -O2 or higher => will not work because of wrongly generated machine code. (Well at least some revisions of the IDE, as it depends on surrounding code) So the same could apply to you building the IDE with 3.3.1. Hence, if you don't by default build with -O- => could you test building you IDE with -O- ? ---- The fact that the alpha vs beta makes no difference is interesting. Then it would seem that it does not matter how the watch value is provided (goes along with the fact it works in hints). But that would mean that the problem is somewhere in the watch window itself. And that is not depending on the underlaying architecture. So it should happen for other people too... (on other OS)... Can you test:   What happens if you add a new watch while being paused? ---------------------------------------------------------------------- Martin_fr · 2023-12-07 17:37 And also, when you step, do the watches in the watch window temporary show "evaluating"? (or at least a hint of a flicker that the window gets updated?) Add a lot of watches (20 or more), so it is easier to spot. ---------------------------------------------------------------------- msintle · 2024-01-03 16:01 Just getting back into this after a prolonged absence due to work demands. Is everything on this thread current, should I just collect the data you had requested earlier, or has anything changed with the new Lazarus 3.0 release? I haven't yet upgraded (fears of breaking my build environment abound) so I don't have an inside look into that version yet. ---------------------------------------------------------------------- Martin_fr · 2024-01-04 16:56 Sorry, lots of other things that I had on my mind since. Trying to recap. - So pretty much any app produces the error? - Type of data does not matter? Simple integer will do. - It will show in the hint. - It will show an (error|nothing|...) in the watches window? (IIRC "invalid")? This is true - if this is the only watch? - even if the watch is added after the app got paused? This is true for - local vars too? - global vars? - fields/other? Do the locals show in the local window? What if you just enter the digit "1" (without quotes) as a watch? It should eval to 1. If so, enter a "1" above and another below the failing watch (do not reorder the watches, clear the watches, and enter them in that order). And yes, a logfile is probably best. ---------------------------------------------------------------------- msintle · 2024-01-08 22:40 Quote from: Martin_fr on January 04, 2024, 05:56:31 pmSorry, lots of other things that I had on my mind since. It is I who owes you the apology. Quote from: Martin_fr on January 04, 2024, 05:56:31 pm- So pretty much any app produces the error? Yes. I just created a new app with this code: Code: [Select]procedure TForm1.Button1Click(Sender: TObject); var   i: Integer; begin   for i := 1 to 11 do     ListBox1.Items.Add(IntToStr(i)); // set breakpoint here end; With just the button and the list box on the form. And indeed, after i = 1 showing properly the first time I stopped at the breakpoint only, sure enough, the issue reproduced instantly the second time I stopped there. Quote from: Martin_fr on January 04, 2024, 05:56:31 pm- Type of data does not matter? Simple integer will do. Yes, per the above sample too. Quote from: Martin_fr on January 04, 2024, 05:56:31 pm- It will show in the hint. Indeed. Quote from: Martin_fr on January 04, 2024, 05:56:31 pm- It will show an (error|nothing|...) in the watches window? (IIRC "invalid")? Absolutely, just says in the Value field, with the square brackets. Quote from: Martin_fr on January 04, 2024, 05:56:31 pmThis is true - if this is the only watch? - even if the watch is added after the app got paused? Yes even then, but not if only then. Doesn't matter! Quote from: Martin_fr on January 04, 2024, 05:56:31 pmThis is true for - local vars too? - global vars? - fields/other? Do the locals show in the local window? Locals vs. globals don't matter. I just added a global variable j to the sample above and set it to i on each iteration of the loop. Interesting observation: The first iteration right after adding j, it worked fine. The second iteration and all subsequent iterations, it became invalid again. The interesting part specifically being, this "state" persists between runs. So when I restart the app after breaking the debug session, everything shows as again. Including j, which had worked for the first time only right after I had added it. Quote from: Martin_fr on January 04, 2024, 05:56:31 pmWhat if you just enter the digit "1" (without quotes) as a watch? It should eval to 1. Great idea! Guess what - worked only the first iteration right after I added it. Stepping through code again, it failed again. Just like j, it never worked even after restarting the debug session. Quote from: Martin_fr on January 04, 2024, 05:56:31 pmIf so, enter a "1" above and another below the failing watch (do not reorder the watches, clear the watches, and enter them in that order). Did that "offline" while the program was in a terminated state. No change. Closed and restarted IDE. Again, no change, everything invalid - isn't that crazy? Not even valid even the first time stopping at the breakpoint! Quote from: Martin_fr on January 04, 2024, 05:56:31 pmAnd yes, a logfile is probably best. That's the only step I haven't done yet. Did I need to recompile the IDE or similar for that? ---------------------------------------------------------------------- Martin_fr · 2024-01-09 00:19 ok, few interesting observations. 1) As the digit 1 also fails => It isn't about getting data from the debugged exe. 1 is just a number, and will be returned as such (it still is evaluated by the debugger, but only the FpDebug part, not the lldb side) 2) This kind of "error is stuck" means something must go wrong globally. There could be an exception of some kind. It might not be reported as it happens in a different thread. Or there could be some memory incorrectly overwritten (dangling pointer or complier issue). I understand you are using FPC 3.3.1 ? That could have bugs (and those could include wrong code generation / has happened before) So - At the very least compile your entire IDE with -O-  no optimizations, minimize the risk. - If you have at hand, try 3.2.2 or 3.2.3  (3.2.2 also may have issues, so also -O- or -O1 / 3.2.3 should be good) Just for info, I spent (meanwhile a year or longer ago) more than 4 weeks searching a bug because FpDebug kept failing. Turned out to be a bug in the fpc 3.2.2 code generator. The generated machine-code simply was wrong. 3.3.1 has a lot of new optimizer additions. So this is a possibility. You can build an IDE with 3.2.3, and then use 3.3.1 to compile your apps. It is only about what was used to build the IDE. ---------------------------------------------------------------------- msintle · 2024-01-09 14:05 OK, I'll fire up a VM to create a new environment and get you the datapoints you need from that environment. Would you mind summarizing exactly what I should be testing and the steps to run those tests? Ex: Logging, rebuilding IDE, etc. Whenever you have the time, of course. ---------------------------------------------------------------------- Martin_fr · 2024-01-09 15:52 Lets try the following 2 steps first 1) Log file You can start with a logfile with no extra preparation. Just run the IDE with (not sure about the exact path, but something like) ./lazarus.app/MacOS/Content/lazarus  --debug-log=file  --debug- enable=DBG_VERBOSE,DBG_WARNINGS,DBG_ERRORS DBG_STATE,DBG_EVENTS,DBGMI_QUEUE_DEBUG,DBG_FPDEBUG_VERBOSE,FPDBG_COMMA NDS,FPDBG_THREADS,FPDBG_QUEUE,DBG_DATA_MONITORS,DBG_THREAD_AND_FRAME And send that log. I can then decide if further logs are needed. 2) Compile the IDE with -O- You can try that with fpc 3.3.1 or whatever you already have (for now) You can just rebuild the IDE from the tools menu "Configure build lazarus" and specify  -O-  -gh  -Sa  -CRiot This will slow it down a bit. Copy your existing exe first (the exe is outside the app bundle ! / next to it / app bundle just contains a sym link) ---------------------------------------------------------------------- msintle · 2024-01-10 16:37 Here's the log file for the first step. We do still need the second step, right? ---------------------------------------------------------------------- msintle · 2024-01-10 16:53 Trying #2 produced this error when I clicked Build: Error: Illegal parameter: -O- ---------------------------------------------------------------------- Martin_fr · 2024-01-10 19:15 -O- minus  uppercase-letter-O  minus https://www.freepascal.org/docs-html/user/userap1.html Strange. It definitely works here. I don't see how this could be OS/Target specific. It simply says: Don't optimize. That should work on all targets. Maybe something to run past the FPC team.... But never mind, after looking at the log, it wont (most likely) be relevant for this case. Currently I assume that some output format of lldb may have changed. Even for a watch like "1" the debugger tries to get the current pause location. As this is needed in many cases. If that fails, it also fails watches that don't need it. While the log has not enough info to trace it all the way, it does give me a start point. Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i GetInfoContextForContext ADDR NOT FOUND for 1, 0 Could you please run the log again, but this time with ./lazarus.app/MacOS/Content/lazarus  --debug-log=file  --debug- enable=DBG_VERBOSE,DBG_WARNINGS,DBG_ERRORS DBG_STATE,DBG_EVENTS,DBGMI_QUEUE_DEBUG,DBG_FPDEBUG_VERBOSE,FPDBG_COMMA NDS,FPDBG_THREADS,FPDBG_QUEUE,DBG_DATA_MONITORS,DBG_THREAD_AND_FRAME,D BG_CMD_ECHO,DBG_CMD_ECHO_FULL Also at the same time please do the following - Before you start the debugger, open the "Debug output" window from the menu "View" > "IDE Internals" > "Debug Output" - Then debug, the window will fill up - Once the debugging is done, copy the content of that window, and attach it here Please alse (re-) confirm: When hovering the mouse and getting a hint on a variable, then the correct result is returned. This is for the same variable as in the watches window. I know you said that before. Just double checking. There is one tiny differences in the debugger code between those 2 cases. If this is a described, then include this in the log as follows. - first let the debugger fail on the watches window - only then / only after the watches failed: Hover and get a hint   (Don't step or run) - kill the debugger: menu Run > Reset debugger   Don't do anything else after the hint => so I can find it as the last value-eval in the log. Btw which exact CPU (M1, M2, M3) do you have? (afaik those are the ones currently avail?) ---------------------------------------------------------------------- msintle · 2024-01-20 17:28 So once again forgive me for the extended delay in getting back to you on this. I've attached the logs you requested and I've followed your instructions to the letter. This is on an M2 CPU, if that makes a difference. To double-confirm as you requested: 0) Yes, as I copy/pasted the flags from here, I definitely used uppercase letter O (not a zero). 1) Hovering always returns correct results. 2) The debugger, as usual, "remembered" its past failure and failed instantly upon reaching the breakpoint. [ To clarify, I did not delete the original testing project, despite the extensive delays I've had in getting back to you] And a question of my own: I find it interesting that there's no comma between the debugger command line flags you specified - this is as intended, right? That's where the new line has been introduced (maybe by the forum), most probably it's nothing but just double checking. ---------------------------------------------------------------------- Martin_fr · 2024-01-20 21:34 I am still looking, but in the meantime. 1) Please try with this patch Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i diff --git a/components/lazdebuggers/lazdebuggerfplldb/fplldbdebugger.pas b/components/lazdebuggers/lazdebuggerfplldb/fplldbdebugger.pasindex 78d21029f5..2a4fa9c37a 100644--- a/components/lazdebuggers/lazdebuggerfplldb/fplldbdebugger.pas+++ b/components/lazdebuggers/lazdebuggerfplldb/fplldbdebugger.pas@@ -1554,6 +1554,9 @@ function TFpLldbDebugger.GetLocationForContext(AThreadId, AStackFrame: Integer):   r := Registers.CurrentRegistersList[AThreadId, AStackFrame];   if (r <> nil) and (r.DataValidity = ddsValid) then    try+      if FDwarfInfo.TargetInfo.machineType in [mtARM, mtARM64] then+        v := r.EntriesByName['PC'].ValueObjFormat[rdDefault].Value[rdDefault]+      else       if TargetWidth = 64 then         v := r.EntriesByName['RIP'].ValueObjFormat[rdDefault].Value[rdDefault]     else  2) Does it affect all stackframes? If you open the stackwindow and select any of the caller frames. Ideally you do that in some code where the callers have debug info, e.g if you make calls from your code to other parts of your code). Can you then get watches for the caller to work? ---------------------------------------------------------------------- Martin_fr · 2024-01-20 22:43 OK, so the findings got odd enough, and my curiosity overcame my "Mac- aversion" -ish. It seems that the watches does not work, if the stack Window is closed. If you keep it open, then Watches will (most likely) work. And it seems the patch makes it work, even if the stack window is closed. I saw the register PC vs RIP before, but since that code worked for everybody else... I thought it couldn't be. Of course tiny difference in what everybody else just happens to do.... ---------------------------------------------------------------------- msintle · 2024-01-21 14:18 Quote from: Martin_fr on January 20, 2024, 11:43:06 pmOK, so the findings got odd enough, and my curiosity overcame my "Mac-aversion" -ish. A friend of mine always says "welcome to the dark side" once one onboards Macs. I have always wondered why! Just asked him, but he has ignored the question before. Quote from: Martin_fr on January 20, 2024, 11:43:06 pmIt seems that the watches does not work, if the stack Window is closed. If you keep it open, then Watches will (most likely) work. And it seems the patch makes it work, even if the stack window is closed. I saw the register PC vs RIP before, but since that code worked for everybody else... I thought it couldn't be. Of course tiny difference in what everybody else just happens to do.... That's the Call Stack window, right? Didn't work for me without the patch. ---------------------------------------------------------------------- Martin_fr · 2024-01-21 14:45 Quote from: msintle on January 21, 2024, 03:18:22 pmThat's the Call Stack window, right? Didn't work for me without the patch. But with the patch it does work? I.e it works no matter if the Callstack is open or closed? It's curious what the exact details are... If it had failed for every one then there would have been more complains (most likely). And the code shows that if the register fails (which indeed it did), then the callstack can be used as fallback... But only if it has been retrieved already. Usually if the stack window is open it gets retrieved before watches... I can't tell if in your case that retrieval order for some reason is not the case, or if the fallback does not work... Please test the following Set a breakpoint in some subroutine that is called by your code. E.g. Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i Procedure TForm1.Foo;begin  sleep(1);         // break hereend;Procedure TForm1.Button1Click;var  MyTestVal: integer;begin  MyTestVal := 12300;  Foo;end; The select the caller  "Button1Click" in the stack. That means "select" = "make it current". Either the green arrow in the toolbar (check the hint(, or the context menu. Can you then see the value of "MyTestVal" in the watches window? Quote from: msintle on January 21, 2024, 03:18:22 pmQuote from: Martin_fr on January 20, 2024, 11:43:06 pmOK, so the findings got odd enough, and my curiosity overcame my "Mac-aversion" -ish. A friend of mine always says "welcome to the dark side" once one onboards Macs. I have always wondered why! Just asked him, but he has ignored the question before. I don't know? For  me it is just inconvenient. The entire user interface is alien to me. I press "home" on my keyboard, which on every OS gets me to the start of the line. On Mac, it takes me to the top of the file (line 1). Ouch. Maybe it's VNC. But without VNC I can't get "dvorak with UK punctuation" (I have that on Windows and on Linux). And that is just one of what feels like a thousand obstacles. ---------------------------------------------------------------------- msintle · 2024-01-21 22:36 Quote from: Martin_fr on January 20, 2024, 10:34:26 pmI am still looking, but in the meantime. 1) Please try with this patch Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i diff --git a/components/lazdebuggers/lazdebuggerfplldb/fplldbdebugger.pas b/components/lazdebuggers/lazdebuggerfplldb/fplldbdebugger.pasindex 78d21029f5..2a4fa9c37a 100644--- a/components/lazdebuggers/lazdebuggerfplldb/fplldbdebugger.pas+++ b/components/lazdebuggers/lazdebuggerfplldb/fplldbdebugger.pas@@ -1554,6 +1554,9 @@ function TFpLldbDebugger.GetLocationForContext(AThreadId, AStackFrame: Integer):   r := Registers.CurrentRegistersList[AThreadId, AStackFrame];   if (r <> nil) and (r.DataValidity = ddsValid) then    try+      if FDwarfInfo.TargetInfo.machineType in [mtARM, mtARM64] then+        v := r.EntriesByName['PC'].ValueObjFormat[rdDefault].Value[rdDefault]+      else       if TargetWidth = 64 then         v := r.EntriesByName['RIP'].ValueObjFormat[rdDefault].Value[rdDefault]     else  2) Does it affect all stackframes? If you open the stackwindow and select any of the caller frames. Ideally you do that in some code where the callers have debug info, e.g if you make calls from your code to other parts of your code). Can you then get watches for the caller to work? 1) Finally got to try this. It fixed the problem! Great job, congratulations!!! Do I still need to complete #2? ---------------------------------------------------------------------- msintle · 2024-01-21 22:46 Quote from: Martin_fr on January 21, 2024, 03:45:17 pmQuote from: msintle on January 21, 2024, 03:18:22 pmThat's the Call Stack window, right? Didn't work for me without the patch. But with the patch it does work? I.e it works no matter if the Callstack is open or closed? Yes, as I just found out; after doing a Lazarus rebuild with the Normal IDE profile. Quote from: Martin_fr on January 21, 2024, 03:45:17 pmIt's curious what the exact details are... If it had failed for every one then there would have been more complains (most likely). And the code shows that if the register fails (which indeed it did), then the callstack can be used as fallback... But only if it has been retrieved already. Usually if the stack window is open it gets retrieved before watches... I can't tell if in your case that retrieval order for some reason is not the case, or if the fallback does not work... Please test the following Set a breakpoint in some subroutine that is called by your code. E.g. Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i Procedure TForm1.Foo;begin  sleep(1);         // break hereend;Procedure TForm1.Button1Click;var  MyTestVal: integer;begin  MyTestVal := 12300;  Foo;end; The select the caller  "Button1Click" in the stack. That means "select" = "make it current". Either the green arrow in the toolbar (check the hint(, or the context menu. Can you then see the value of "MyTestVal" in the watches window? I didn't run this test case either, but I did select the first stack frame displayed (before applying the patch) and it had made no difference (with my original test project). Do you really need these stack based tests anymore? Can I finally delete my original test project? Do we understand how the mechanism was for the IDE to "remember" the broken variable watches even across IDE restarts (since they worked for the first time they were added only)? This is a huge mystery for me still, but one that is safe to ignore of course. Quote from: Martin_fr on January 20, 2024, 11:43:06 pmQuote from: msintle on January 21, 2024, 03:18:22 pmQuote from: Martin_fr on January 20, 2024, 11:43:06 pmOK, so the findings got odd enough, and my curiosity overcame my "Mac-aversion" -ish. A friend of mine always says "welcome to the dark side" once one onboards Macs. I have always wondered why! Just asked him, but he has ignored the question before. I don't know? For  me it is just inconvenient. The entire user interface is alien to me. I press "home" on my keyboard, which on every OS gets me to the start of the line. On Mac, it takes me to the top of the file (line 1). Ouch. Maybe it's VNC. But without VNC I can't get "dvorak with UK punctuation" (I have that on Windows and on Linux). And that is just one of what feels like a thousand obstacles. Yes this was a mess for me also. The shortcuts are all different and not all of them seem to make a ton of sense. Command + Left / Command + Right are the equivalents of Home and End (Command would be the Windows key). Don't hesitate to ask if you have any other shortcut questions! Once you get used to it, it is quite addictive - like using a PC was in the good days of the PC. Oh, my friend also replied to my question as follows: "Just for fun.  I could easily say welcome to the light side, but it is not as fun." ---------------------------------------------------------------------- Martin_fr · 2024-01-21 23:49 I don't know for sure how the IDE "remembered". Too many possibilities. The IDE has/had 2 ways of getting the data - the broken register (never worked) - via the internal data for the stack For the top stack frame: The latter is by design "not required to work", because the first should always work. The latter is just there because there is an "exit" missing, if the first fails. (but then it's ok to be there...) So it is not important to find why the 2nd does not always work (it isn't meant to) Well, that is: If it did not work, because the data was not available. If the data was broken, then that is an issue. As for the difference between your and my experience: The latter (data availability) depends on lots of things. In the end it is a timing issue (almost like a race condition, though often a bit more predictable). Like for me it worked when the stackwindow was open. But that part did not work for you. So there is some other factor. It is possible that whatever caused this different gets saved into the session or project. About the "select the 2nd stack frame". When you select any stackframe, other than the top, then the above rules change. - The register is never used - the stack data is always used But, then the data should always be available. - The above "not working" meant "not working, because data not avail". - So if for the 2nd frame the data is avail, then it should work. That is why I asked the question. - Until now, I can just assume that when you had the stack open, but it still did not work => it was timing (data not available) - But in theory, maybe something was wrong with that data (a 2nd independent bug) Checking if watches work in the 2nd frame, would tell for sure which one it is. Otherwise you or someone find out one day, when they really need it. (I kind of assume (again..., I assume a lot) that it works for most, because no one complained yet, and at least when I debug I use the stackframes all the time. But since on the machine I logged into, the behaviour is a little different from yours, I can't rely on my tests alone. In the end, most bugs get fixed when they get reported. - For Windows and Linux I have limited automated tests. - On Windows I use the debugger a lot, so it gets heavily tested - On Linux I use it a little, so it gets some testing - On Mac, I relay entirely on others reporting issues (exception like now, when I have a report and jump over my shadow and log into a Mac) However, there are a few people in the developer team who use Mac, and they obviously to debugging. So there is at least some regular use of the debugger on Mac. ---------------------------------------------------------------------- msintle · 2024-01-22 01:08 Thanks for sharing all that! So do you need me to do anything else right now for you? ---------------------------------------------------------------------- Martin_fr · 2024-01-22 09:05 Well as I said, if you can, please test the 2nd stack frame https://forum.lazarus.freepascal.org/index.php/topic,65438.msg503159.h tml#msg503159 Otherwise all good. ---------------------------------------------------------------------- msintle · 2024-01-22 11:46 Quote from: Martin_fr on January 22, 2024, 10:05:36 amWell as I said, if you can, please test the 2nd stack frame https://forum.lazarus.freepascal.org/index.php/topic,65438.msg503159.h tml#msg503159 Otherwise all good. No worries, I sure can. So before doing this test, you would like me to roll back the patch of course, right? Just making sure so by the time I get to it, I'll have all the remaining answers you need. ---------------------------------------------------------------------- Martin_fr · 2024-01-22 12:48 Quote from: msintle on January 22, 2024, 12:46:34 pmQuote from: Martin_fr on January 22, 2024, 10:05:36 amWell as I said, if you can, please test the 2nd stack frame https://forum.lazarus.freepascal.org/index.php/topic,65438.msg503159.h tml#msg503159 Otherwise all good. No worries, I sure can. So before doing this test, you would like me to roll back the patch of course, right? Just making sure so by the time I get to it, I'll have all the remaining answers you need. No, you can keep the patch in. ---------------------------------------------------------------------- msintle · 2024-01-22 14:07 Quote from: Martin_fr on January 22, 2024, 01:48:49 pmQuote from: msintle on January 22, 2024, 12:46:34 pmQuote from: Martin_fr on January 22, 2024, 10:05:36 amWell as I said, if you can, please test the 2nd stack frame https://forum.lazarus.freepascal.org/index.php/topic,65438.msg503159.h tml#msg503159 Otherwise all good. No worries, I sure can. So before doing this test, you would like me to roll back the patch of course, right? Just making sure so by the time I get to it, I'll have all the remaining answers you need. No, you can keep the patch in. I don't understand. With the patch, there's no issue at all with the variable watches window; but the post you linked to for the test you'd like me to do asks if the variable watches resolve correctly after doing something with the call stack window - which by that point serves no purpose, doesn't it? ---------------------------------------------------------------------- Martin_fr · 2024-01-22 14:41 If you select ("set as current" any stackframe other than the top frame, then the register will never be used. So it does not matter if the register-patch is applied or not. In other words: 1- The bug I fixed, does not (and never has) affected any watches on the 2nd (or further down) stackframe 2- But, the open stack window, did not help as workaround on your setup (yet it did on mine). (2) Can be explained by either - This can happen, and it can happen without any bug present - This can happen if there is a 2nd bug (of which we don't yet know). So to make sure there is not such 2nd bug, it should be tested. See the image. The stack can be selected with either the "green button" or from the context menu. The selected stack has the small green arrow at the left side of the line (before the number, where the grey dots are). If you select the 2nd stack, then variables from the current function/procedure may show "Identifier not found" => that is correct. Instead you can see variables from the selected stack. ---------------------------------------------------------------------- msintle · 2024-01-22 21:37 Quote from: Martin_fr on January 22, 2024, 03:41:55 pmIf you select ("set as current" any stackframe other than the top frame, then the register will never be used. So it does not matter if the register-patch is applied or not. In other words: 1- The bug I fixed, does not (and never has) affected any watches on the 2nd (or further down) stackframe 2- But, the open stack window, did not help as workaround on your setup (yet it did on mine). (2) Can be explained by either - This can happen, and it can happen without any bug present - This can happen if there is a 2nd bug (of which we don't yet know). So to make sure there is not such 2nd bug, it should be tested. See the image. The stack can be selected with either the "green button" or from the context menu. The selected stack has the small green arrow at the left side of the line (before the number, where the grey dots are). If you select the 2nd stack, then variables from the current function/procedure may show "Identifier not found" => that is correct. Instead you can see variables from the selected stack. Great news, it worked just fine. OK to delete the test project now? Very interesting trick to know, by the way. ---------------------------------------------------------------------- Martin_fr · 2024-01-22 23:51 Quote from: msintle on January 22, 2024, 10:37:09 pmGreat news, it worked just fine. Good, thanks for testing. QuoteOK to delete the test project now? Yes, well, as you like. QuoteVery interesting trick to know, by the way. ---------------------------------------------------------------------- msintle · 2024-01-23 00:57 Thanks for all the help!