Finally, I have no plans of tackling this but can fpDebug be used to fix the orginal issue?
You mean, original issue = "fpc does not print the line numbers"?
No fpdebug will not help there.
Well, I am not part of the compiler team, but this is my understanding.
Fpc has for each platform (well most....) a unit with a minimal debug info (dwarf and/or stabs) reader.
This reader is
1) kept as small as possible (otherwise the end user app get a lot of extra code)
2) written to work with minimal resource requirement. I.e. ideally a very small statically allocated bit of memory.
The 2nd part is important. Stack dumps may happen after an app crashed. The memory management may be corrupted. If you try to get memory, then that would crash the stack dumper.... not helpful.
FpDebug is made for a full blown debugger. It uses memory as it sees fit. And of course it can do more that just read line info, and separating this out would be quite some work.
Of course it depends on the use case....
If you want the stack dump only for your debug builds, then you would not mind if some more code is added.
And for release builds, you should actually (if anything at all) only dump addresses. Your clients do not need the unit names. And you can use leak view to resolve the addresses.
(you need to build your release with debug info, keep a copy, and use strip on the version you ship)
Also note: Even on platform where fpc dumps the line numbers, it has safety nets build in (as again, the app may have crashed, making it unsafe for any code to do anything).
So if it comes to any line, that simple has no line number, it assumes there may be a problem, and it will stop printing line numbers, and do address only for the rest. (At least that is what it used to be).
The leak view, will continue looking, and pick up, if there is more info further down the stack.
Finally, for errors it is best to try and stop them in the debugger.
Of course mem leaks, you need the dump
If you want to collect a lot of traces, because you do not yet know what/where the error is, and you want the last trace before an error (crash/exception) happens... => the debugger can do that.
- Set a breakpoint.
- Go to the breakpoints properties (right click the breakpoint)
- uncheck "break"
- check take a snapshot
This will record the top 5 frames, if you need more, keep the stack window open.
The recorded snapshots can be accessed via menu: view > Debugger > history.
Double click a history entry to activate it, and the stack window will show the history.
https://wiki.lazarus.freepascal.org/IDE_Window:_Debug_History