At 19:12 4-11-2004, you wrote:
Peter wrote:
>The quick fix for it will be to disable the dump_stack call after an
unhandled exception is found.
That gets rid of the junk, but I still lose the call stack.
>Alternative solution is to retrieve the caller stack at the time an
exception is raised. Bu
Peter wrote:
>The quick fix for it will be to disable the dump_stack call after an unhandled
>exception is found.
That gets rid of the junk, but I still lose the call stack.
>Alternative solution is to retrieve the caller stack at the time an exception is
>raised. But that will take more cpu t
At 00:04 4-11-2004, you wrote:
Compiling sysutils with -gl gave the call stack seen below... insightful,
I suppose, but not necessarily useful ;)
It definitely points to what Peter said about the ansistring finalize
writing to the same place in the stack. Examining the stack, it seems that
dump
Compiling sysutils with -gl gave the call stack seen below... insightful, I suppose,
but not necessarily useful ;)
It definitely points to what Peter said about the ansistring finalize writing to the
same place in the stack. Examining the stack, it seems that dump_stack calls
get_caller_addr, a
Peter wrote:
>The problem is that the call to the empty ansistring routine will create a
>temp ansistring for the parameter. And ansistring variables or temps need
>to be finalized. This call to finalize() destroyes the backtrace since it
>writes at the same location in the stack that was also use
> We've got a sophisticated system which relies heavily on the power of ansistrings.
> I'm now introducing exception handling into the system, and am running into problems
> with the pascal call stack.
>
> Without exception handling, I get a nice pascal stack, such as the following
> (produced
