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

[Schatzl Thomas]

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...

Another one might be that for every line info retrieval, the whole debug info is parsed because afair FPC does not generate the DWARF optional lookup table for searching for a compilation unit given an address (i.e. the .debug_aranges section).

Hth,
  Thomas

-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser