Lazarus 3.9.9 Variable Watches Fail (But Debugger Tooltips Work!)

[msintle]

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]

Really need an example to reproduce.

Any kind of variable, specific ones?
What settings?

[msintle]

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]

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]

The 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]

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)

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]

I regret the delay in getting back to you!

With 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).

Project > 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?)

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]

The 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 <invalid>.

This is just an ordinary string variable, in scope, recently assigned, working in the editor tooltip.

[msintle]

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)

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]

LLDB (the only debugger that works on recent macOS releases),

"LLDB (alpha)" or "LLDB (with fpdebug)"?

[Martin_fr]

Also not sure if relevant, but:
- params listed in the stackwindow - ok or not?
- locals window?

[Martin_fr]

macOS 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][+][-]

1. -O-
2. -Sa  
3. -dDBG_VERBOSE
4. -dDBG_WARNINGS
5. -dDBG_ERRORS
6. -dDBG_STATE
7. -dDBG_EVENTS
8. -dDBGMI_QUEUE_DEBUG
9. -dDBG_FPDEBUG_VERBOSE
10. -dFPDBG_COMMANDS
11. -dFPDBG_THREADS
12. -dFPDBG_QUEUE
13. -dDBG_DATA_MONITORS
14. -dFPDBG_DWARF_ERRORS
15. -dDBG_THREAD_AND_FRAME
16.  

And then, if it still happens run Lazarus with
--debug-log=somefile.txt

and submit that file.

[msintle]

LLDB (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]

Also 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]

macOS 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.