On Sat, 14 Nov 2009, Martin wrote:
Martin wrote:
I'll have to withdraw it.
I have no idea how I compiled an exe that actually did not crash when
dumping a stack (yes I had one.). but the patch doesn't work.
I had that right,, just the debugger confused me the way it displayed the
On 14 Nov 2009, at 11:16, Michael Van Canneyt wrote:
I don't think that the thread-safety is something to worry about at this
time; As you remark, the code was already not thread-safe. But it is
something to keep in mind.
At the very least this bug should be documented, and a {$warning
On Sat, 14 Nov 2009, Jonas Maebe wrote:
On 14 Nov 2009, at 11:16, Michael Van Canneyt wrote:
I don't think that the thread-safety is something to worry about at this time;
As you remark, the code was already not thread-safe. But it is something to
keep in mind.
At the very least this
On 14 Nov 2009, at 11:30, Michael Van Canneyt wrote:
On Sat, 14 Nov 2009, Jonas Maebe wrote:
At the very least this bug should be documented, and a {$warning ...} should
be added at the appropriate place in the source code so that someone
interested in fixing it can do that right away
On 14 Nov 2009, at 12:19, Michael Van Canneyt wrote:
On Sat, 14 Nov 2009, Jonas Maebe wrote:
I can't follow here. There was an undocumented problem in a unit, and now
that it has been identified and sort of made worse, there is no need to tell
our users about it?
Well, IMHO without
On Sat, 14 Nov 2009, Jonas Maebe wrote:
On 14 Nov 2009, at 12:19, Michael Van Canneyt wrote:
On Sat, 14 Nov 2009, Jonas Maebe wrote:
I can't follow here. There was an undocumented problem in a unit, and now that
it has been identified and sort of made worse, there is no need to tell our
Michael Van Canneyt wrote:
On Tue, 10 Nov 2009, Schatzl Thomas wrote:
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
I'll have to withdraw it.
I have no idea how I compiled an exe that actually did not crash when
dumping a stack (yes I had one.). but the patch doesn't work.
Problem I have is how to deal with the open var param.
I need to be able to address the first (or other) byte of it
function
Martin wrote:
I'll have to withdraw it.
I have no idea how I compiled an exe that actually did not crash when
dumping a stack (yes I had one.). but the patch doesn't work.
I had that right,, just the debugger confused me the way it displayed
the values.
Attached patch works here, and
Hello,
Von: Martin laza...@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
On Tue, 10 Nov 2009, Schatzl Thomas wrote:
Hello,
Von: Martin laza...@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
On 10 Nov 2009, at 11:32, Michael Van Canneyt wrote:
By making the buffer a threadvar, this should not be an issue ?
It will waste memory for each thread you start though, for
functionality that you hopefully won't need anyway.
Jonas
___
On Tue, 10 Nov 2009, Jonas Maebe wrote:
On 10 Nov 2009, at 11:32, Michael Van Canneyt wrote:
By making the buffer a threadvar, this should not be an issue ?
It will waste memory for each thread you start though, for functionality that
you hopefully won't need anyway.
Correct.
But
Schatzl Thomas wrote:
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
Micha Nelissen schreef:
Schatzl Thomas wrote:
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
On 10 Nov 2009, at 11:57, Michael Van Canneyt wrote:
But let's start by improving efficiency, the MT issue can follow
later :-)
I disagree. I think correctness should always be more important than
efficiency, especially for RTL functions (and in particular when it's
about debugging
Vincent Snijders wrote:
Micha Nelissen schreef:
Schatzl Thomas wrote:
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
Vincent Snijders vsnijd...@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
Vinzent Höfler wrote:
Vincent Snijders vsnijd...@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
19 matches
Mail list logo
