Waldek Hebisch wrote:
Backtrace for fjf659o.pas:
Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x000e6014
Thread 0 Crashed: 0 a.out 0x0000eeb4 _p_Write_Init + 0x34 (files.pas:518) 1 a.out 0x0000231c _p__M0_main_program + 0xac (fjf659o.pas:10) 2 a.out 0x00002470 main + 0x34 (<implicit code>:12) 3 a.out 0x00001ea8 _start + 0x188 (crt.c:267) 4 dyld 0x8fe1a558 _dyld_start + 0x64
Looks like _p_Write_Init is accessing freed file. We either need `Finalize' to set its argument to an invalid file (FDR) or to nil. In the second case all IO routines would have to check for nil.
First of all, fjf659o.pas is a strange test program anyway. I was wondering about it, and it was on my list of things to have a closer look at again. So if it fails now, I don't consider it serious anyway.
It's supposed to test that `Finalize' does something for files. But what exactly it does, might better be left undefined. So, when the test program checks for a I/O error that can be caught, this might simply be too optimistic. (And file handling has changed internally since it was written, so it's possible that originally, it either caused a bad access that wasn't noticed, as now, or it didn't and does now.)
Anyway, I'm ready to retract this test program, unless it's really a symptom of a real problem (which it doesn't seem so far). Or to change the test program to test it somehow differently (not sure yet exactly how, but perhaps there's something with low-level TFDD interfaces, I'll try it ...)
Frank