Do you mean that BackTraceStrFunc itself is slow, or that stepping into or over BackTraceStrFunc calls during debugging in Lazarus is slow?
The BackTraceStrFunc itself is slow, both during debug and when a compiled application is executed.
Yes, this (i.e.: that it is slow / not that it is slower than in older versions) is known.
One of the use-cases for the backtrace BackTraceStrFunc is to be called
after a crash.
After a crash "nothing can be trusted". Meaning:
- the application can be in any state
- the memory or stack my be corrupted (I.e. data may have been written to memory via a dangling pointers. Important parts of the stack, mem-manager-structures may be destroyed)
With this in mind, any further code that is executed (including the BackTraceStrFunc) may crash again.
The BackTraceStrFunc has been written to minimize the chance of such further crashes. But that means a lot of limitation, and that does have a severe effect on the speed.
I don't know why it is slower now, than before.
I don't know what OS and what bitness (32/64) you use?
Afaik for some targets, the default debug format changed (at some point, not sure if between 3.0.4 and 3.2.2) from stab to dwarf. (For some targets, stabs in no longer supported, so you may not even be able to force it).
Maybe the dwarf version of BackTraceStrFunc is slower.
Depending what you try to do, there are other ways.
If you need traces yourself, running on your own machine:
You can use the debugger, you can:
- set a breakpoint, and edit its properties
Property "break" = false
Property "snapshot" = true
You can then open menu: View > Debug Windows > History
There you will find an entry for each time the breakpoint was passed.
By default the top 5 frames are collected. But if you have the Stack window open, the stack window is set to 10 or more frames, then they will all be collected.
This will be faster than BackTraceStrFunc, but still a slow down.
To minimize the slow down, delete all watches from the watches window. (Watches are also collected for the history snapshots).
Ensure you use FpDebug, which is faster than GDB. (Well if you are on Mac, then its LLDB-based (FpDebug+LLDB) and that can't be changed).
You can further use breakpoints in the calling code to enable/disable the "snapshot breakpoint".
Thus only taking snapshots, if the function was called from certain functions (or not called from certain functions)
Search the wiki for "breakpoint properties"
If you ship this in your release, so clients can send back traces...
(Well you can try this local on your machine too)
- Compile the EXE with debug info (ideally
not "external debug info")
- Copy the compiled exe
- use "strip.exe" (on Linux, just "strip") on one of the 2 exes.
=> So now you should have
- MyApp.exe -> after "strip MyApp.exe"
- MyApp-Copy.exe -> that was
not stripped. (So still with debug info)
Important is that
both files are from the same compilation-run. The same invocation of "fpc MyApp.pas".
Now if you run MyApp.exe (the stripped/small one, without debug info) you will get backtraces, that are address only. No filename or lines.
But the traces should be a bit faster (still take some time)
You can copy and paste this trace into: menu View > Leaks and traces
And the press "resolve" and select the MyApp-copy.exe (with debug info).
That should give you the filenames and lines.
Test it before shipping a release.
Mind the filenames/line-numbers are only correct if
both files are from the same compilation-run.
While I wrote this you mentioned your OS.
Afaik Win64 is now dwarf only. Stabs no longer possible.
So maybe that is why it is slower now...
Or maybe bug fixes in BackTraceStrFunc
Recent
