Adriaan van Os wrote:
Frank Heckenbach wrote:
Waldek Hebisch wrote:
Adriaan van Os wrote:
procedure Finalize1; begin FlushAllFiles; RestoreTerminal (True); Done_Files; if ErrorMessageString <> '' then WriteStackDump end;
Does Done_Files also operate on StdErr ?? The crash disappears if I comment out the Done_Files call;
It looks so (Frank knows better). Good catch.
Ouch! Yes, `WriteErrorMessage' accesses (via `FileHandle') a field of already disposed `StdErr' variable -- an evil bug, as it happens to work often (especially if the field is in the middle of a bigger structure, as is the case here), so it wasn't noticed so far. But, of course, it's wrong, and now it crashed ...
`Done_Files' probably should go after `WriteStackDump'.
Yes, try swapping the two statements.
It works OK now. Don't we need a testsuite program to test for proper handling of runtime errors ? The rts problem went unnoticed in the previous alpha version. Not sure how to do that. Cause a runtime error and then check the exit code in a shell script ?
We do something like this in several test programs, and mishandling is usually noticed (as you did).
The problem here was really that accessing an field of a disposed variable often works (because the memory still contains the old value, even if it is unallocated), so no test could have noticed it. (Except for general automatic runtime checks for dangling pointers, but as you can probably imagine, they'd be very expensive, similar to checks for undefined variables).
Frank