In reply to a message from "Re: Help me collect debug-issues"
This reply is to help (and/or describe what is known) with the current situation. (That is until such time, when proper fixes are in place)
the assembly level debugger. It pops up when I simply want to debug my Pascal code, and although I can 'step over' or step out' , what I want to do is 'jump back to dry land.'
If that happens when
stepping over (F8) a function call:
That is a known problem with the
"gdb based" debugger only. (The issue is either caused by GDB, or by something in the debug info created by FPC / the exact reason has never been pinpointed).
- If you need to use the GDB based debugger: Tools > Options > Debugger > backend: In the "property grid", find an activate "FixIncorrectStepOver"
- However, rather than using the GDB based debugger,
it is recommended to use FpDebug / LazDebuggerFp
https://wiki.lazarus.freepascal.org/LazDebuggerFp If you are still on
Lazarus 2.0.x then you may have to install the package.
If you are on
Lazarus 2.2.0 then you just need to select it in: Tools > Options > Debugger > backend
See also
https://wiki.lazarus.freepascal.org/Debugger_Status and
https://wiki.lazarus.freepascal.org/DWARFAs for other cases, when the assembler opens...
The most common run time errors are SIGSEGV which might be due to accessing a char S[1] of an empty string, or a StringList or other object not yet created, or column 6 of a grid that only has 6 columns, you know the usual things, so I need the debugger to place a cursor on the last line of MY code that was processed, which usually gives me a clue what I have done wrong.
The debugger has some code that
should find the first stack-frame with Pascal code.
- Of course that is if the stack has a frame with Pascal code.
- That search might be limited to a small number of stack-frames at the top of the stack.
So indeed, this may not always work.
This is on the TODO (and unfortunately has been there for a longer while).
I also find sometimes that the 'Call Stack' only contains assembler/memory addresses and no actual Pascal unit/procedure names, or standard units/procedure names and none from my actual program. so no help in finding out what task was in progress when the error came.
As for "stack has a frame with Pascal" => If the stack ends early (no more frames at all):
- This can happen with GDB and FpDebug
- For the stack-unwinding: GDB is often better than FpDebug (GDB may return more frames than FpDebug)
One (of many issues):
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39555Also todo...
Most of the time I don't even want to step through the code of the standard Lazarus units, just my own code. Simply, I think the debugger should only place the user in assembler debug if they have specifically asked for it.
Compile the LCL and packages without debug info.
1) Menu: Tools > Configure Build Lazarus => Ensure to chose a profile without debugging (no -gw -gs -g?? switches)
2) Ensure those packages do not have debug info enabled (package options)
Or maybe easier: Project Options > Additions and Overrides (search wiki): New entry for *all* packages, but not the project: -g-
(not tested, but I think it should do)
As you might guess I haven't explored the options for debugger, no doubt there is one that would banish the assembler panel for ever, but my proposal is that should be the default.
The only option is to "auto close" it, if you continue debugging.
The reason why there is no other option is that if your program gets paused in the debugger, the debugger needs to show you some location.
Well ok, that could be disabled, but then the debugger just pauses your app, and you are no wiser. There would be no location, on indication, no nothing....
Obviously, if a Pascal code location can be found, that should be found. So this is where fixes need to happen.
In rare cases, this may not be possible. E.g. if you app crashes, because the stack got totally corrupted. Then the only thing the debugger can find is the current instruction pointer (to an asm instruction). If that asm instruction is not in any known Pascal source, well then nothing can be found.
In the majority of cases, that is not the case. Something could be found. But the debugger is not smart enough. (Or if it relies on GDB, gdb may not have been smart enough).
Anyway, there certainly are cases that can be fixed.
Depending on which of the above case you experience, you should try which of the 2 debuggers (gdb / fpdebug) is better for you.
The other thread "Re: Help me collect debug-issues" is about the "dab debugger" (an add on to Lazarus, not part of the distro) - But issues collected there also apply to the FpDebug debugger. (Same code base).
Some fixes may be independent of the chosen debugger. (and may be fixed for fpdebug and gdb...)
You can always report specific examples (including mentioning if you use gdb or fpdebug, and what OS you have).
They should ideally come with a ready to test mini/sample project, that reproduces them.
It can then be checked in which category each of them falls. (And if they are know issues)