Forum > Debugger

State of debugger (LLDB)

(1/2) > >>

Grahame Grieve:
I'm using trunk Lazarus/FPC on Mac(M1/Max) Monterey.

the debugger doesn't seem to wrk very well. I get errors like SIG_CHILD that aren't anchored in my code - are they real? I don't know.

I get an exception ESC_BAD_ACCESS in TEncoding.UTF8.getString. That doesn't make sense to me but if I try to look at the parameters being passed to it, I can't see local variables, and putting watches on them seems to operate unreliably - not updated, an <illegal value> when it's certainly not illegal (value set to 0 etc). And I can't see a TBytes at all.

Is this where the debugger is? or is there some problem with my compile settings? Is there a reason to get BAD_ACCESS in TUTF8Encoding? or is the stack wrong, since the buffer should be valid.... (I can't really check?) Is this a threading issue? it's not happening in the primary thread...

Martin_fr:
Well, really hard to tell....
The biggest problem is, that the Debugger for the Mac is more or less without maintainer. I maintain Win and Linux. I don't know how much Joost is looking at the Mac.

Anyway this sounds like more than one issue.

Suspected behavioural changes....

This would be down to how well lldb (which is part of what Apple delivers) works. The only changes a debugger makes is setting breakpoint, which modifies the code. But normally the app never gets to know that. Well and it changes timing, which can be relevant if threading is in play.

Well there is one known issue known in the GDB world. That is, it happen using GDB, but the bug may be in either GDB, FPC or both.
https://gitlab.com/freepascal.org/fpc/source/-/issues/39499 (and maybe related https://gitlab.com/freepascal.org/fpc/source/-/issues/38117 )
I have no idea, if LLDB may be affected by this too.
But any of those, would ONLY happen if you have breakpoints set. (and have them set as described in the issue).

In menu View > Ide Internals > Debug output you can watch the LLDB commands and responses. Maybe they contain some clues.

You can also get them by enabling a log, as described in this post https://forum.lazarus.freepascal.org/index.php/topic,42869.0.html
EXCEPT: I have recently gotten several "empty" logs. So possible the logging is currently broken. Still to be established.


Watches / accessing Data.

Make sure to stick with zero optimizations -O-
(Not even O1)

Watches are done by the IDE. lldb is used to read memory, but the interpretation of the memory is done by FpDebug (lldb doesn't know that much about Pascal data).

I added the support for M1 with the help of feedback by other users. I can't actually test it myself. So that leaves a lot of potential for issues.
The only known diff so far is the different register names.

There is a LazDebuggerLldb package (with NO "FP" in it). This is pure LLDB, it will ask LLDB to get the watched value as string and display what lldb gave back.
( using this FpDebug free version, one may experiment with the fpc option -gw2 -godwarfsets -godwarfcpp ).
So this may be a way to see, if those values can be retrieved.

Other than this, I would need at least a logfile (as above, and assuming logging works).
And later maybe a pre-compiled exe (to test what FpDebug can read from it), extracted dwarf data (objdump), ....

One way would be to add writeln into your exe, not to replace the debugger, but to verify it.
If you writeln the locals, to console (for tbytes start with "writeln(ptruint(pointer(the_var)));" as a separate writeln. So you can see if the internal pointer looks ok.
Then if writeln succeeds, but the debugger does not, at least it is clear that it is the debugger (after all, the data could be faulty).

Also, if you mix that with logging, you can see what the debugger does.
If writeln says the TBytes point to 0x0123456 then the debugger at some time should send a command to lldb to read this memory. If it does not, then that is a first clue...

Also it would be good, if you could check if the problems also exist with fpc 3.2.2 (or 3.2.3).
For example there are some Window specific issues between FpDebug and 3.3.1. But I had no time yet to check any details, except they are SEH related, so should be WIN only.

Martin_fr:
One note about local variables (and parameters).

If you are either just stepped in (and the execution is on the "begin" keyword), or you are at the "end" keyword of the procedure/function, then locals may be inaccessible. (though that affects either the locals windows AND the watch window / or neither).

This is the case for any debugger, and on Mac,Linux and Win.

The reason is, that Locals (including parameters) are accessed on the stack via the FrameBase register. This is being setup in the "begin" line, and torn down in the "end" line. So in those lines the FrameBase will not be initialized, it will be random (from the point of view of the debugger), and values retrieved can be wrong or un-readable.

Martin_fr:
Ok, so I got some testing done with LLDB under Linux. (Back in 2018, I had trouble finding a stable lldb for my (back then slightly older) distro. But nowadays lldb on Linux is easy to get.

I found an issue that would severely affect the display of any watches/locals/...
Strange that no one had complained before.

https://gitlab.com/freepascal.org/lazarus/lazarus/-/commit/2187550bd5ade40eaf36266cd65cd685fd10e3ce#d589f4071ffc189b04825ba02e6e9eef54996270

- The *gdbmi" file does not matter for you, different debugger.
- You need the changes from fplldbdebugger.pas

You can just edit your local file and rebuild your IDE.

This issue is about showing watches/locals. It has nothing to do with sig-faults reported in your app. Unless the errors you saw were in the IDE, and not in your app. The bug fixed in the above commit, could cause the IDE itself to have sig-faults.


The issue is nearly as old as the lldb-based debugger itself. Which could also mean it was hidden by something else until now.
Because back then, I was running an automated testcase. Well part of it [1].
And today that testcase crashed due to the bug.

[1]
Unfortunately the code in the test target-app (the app, that is debugged by the testcase) crashes lldb when it reaches a certain breakpoint.
So I can only run part of it.
Since the same file is used to test other debuggers, it's a bit trickier to make an lldb friendly version of it.
(lldb does not like functions with too many arguments, in this case hundreds)


The core issue remains though. I am not using the fp+lldb debugger myself. So I wont spot bugs in it. They need to be reported. And the reporter may have to help by providing logfiles and feedback (unless the issue also happens on Linux, and there is enough info to reproduce it).

I can at least now run the testcase (or whatever part of it works).
- But that is very little.
- Usually only happens when I have big changes. There are too many tests, and running all of them takes many hours, and then further time to review the results.

Grahame Grieve:
ok thanks. So I'm starting to get used to Lazarus on a Mac. First concrete issue:

    raise ELibraryException.create('File "' + filename + '" not found');

the doesn't exist, so this exception is raised. This is what the debugger gives (attached), for the debug output also attached. Then the assembler window comes up, and there's no way to figure out the stack - the stack view is empty, and doing anything just goes back to the program

Navigation

[0] Message Index

[#] Next page

Go to full version