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, and then I assume the access violation is about the address being unfindable since it's been overwritten.
1.9.5 (today's w32 binary) didn't work any better
re: Peter's last comment: so I guess the finalization of that temp ansistring is done at the end of play_with_strings, rather than being done within play_with_strings just after completion of the call to do_nothing_with_an_ansistring ... but it still irks me that the temp ansistring is created even if the function requiring it is not called. Oh well.
Has this been filed as a bug? (Is it considered a bug? I should hope so) ... for now, I guess I'm condemned to always be recompiling with a directive to either handle exceptions or see a call stack. I can live with that (as if I have a choice!)
The quick fix for it will be to disable the dump_stack call after an unhandled exception is found.
Alternative solution is to retrieve the caller stack at the time an exception is raised. But that will take more cpu time and more memory.
Peter
_______________________________________________ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
