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

Martin lazarus at mfriebe.de
Tue Nov 10 23:04:57 CET 2009

Vinzent Höfler wrote:
> Vincent Snijders <vsnijders at vodafonevast.nl>:
>> Micha Nelissen schreef:
>>> Allocating that buffer on the stack isn't sufficient?
>> That's not easy when the exception is raised in case of a stack overflow.
> In case of a stack overflow *anything* using the stack is doomed. But if we're talking about checking the stack it shouldn't be too hard to add some safety bytes to the check, should it?
> But honestly, I don't understand the issue at all: How often would it happen that several threads try dumping their stack at the same time? In the real world, I mean?
Well developperrs can explicitly call the stackdump, even if no crash 
has occurred.

And if memory is corruupted, then a lot of threads may crash at the same 
time. With a single stacktrace taking half a minute at current, they can 
easily intersect....

> I'd be for allocating the buffer statically and for MT safe code you still can add critical sections later. After all, dumping two stack traces at the same time wouldn't be very readable, neither. ;)
The best would be a non OS-dependend, cpu based spinlock, or similar.
The asm implementation would have to be created once for each cpu. 
(making sure the cache is bypassed). Then stacktraces, can be dumped one 
by one.

More information about the fpc-devel mailing list