[fpc-devel] time for dumping stacktrace, when using dwarf.

[Michael Van Canneyt]

On Tue, 10 Nov 2009, Schatzl Thomas wrote:

> Hello,
>
>> Von: Martin <lazarus at mfriebe.de>
>
>> Just to make sure I don't to anything silly.
>>
>> When an application crashes, it usually (at least in Lazarus) dumps a
>> stacktrace to the console.
>>
>> I used to use stabs, and the stacktrace was dumped in less than a
>> second.  Now I have switched to dwarf  and the same stacktrace (maybe
>> 15 frames) takes long enough to get a coffee (well ok, not, but at
>> least 10 seconds or so...)
>>
>> Is that normal?
>
> from rtl/inc/lnfodwrf.pp:
>
> { Current issues:
>
>  - ignores DW_LNS_SET_FILE
>  - slow
> }
>
> The main reason for this slowness is that that implementation (of mine) reads debug info byte-by-byte from the input stream using blockread(). I think this I/O the main performance bottleneck.
>
> At that time I did not bother improving this since it is sufficient for my purposes. I did not test with very large debug infos because on my development platform Lazarus does not work >:)
>
> Improving upon that should be trivial, all reading from the debug input has been encapsuled in the two ReadNext() methods in the file mentioned. It should be easy to make them to read from a (static?) buffer that is filled blockwise; note that a static buffer may give headaches for MT programs, and you are strongly discouraged to do memory allocation during crashes...

By making the buffer a threadvar, this should not be an issue ?

I was glad to read your answer, because I was having the same problem as Martin.
I ended up by simply disabling the stack trace.

Michael.