Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!hao!oddjob!gargoyle!ihnp4!ihwpt!knudsen From: knudsen@ihwpt.ATT.COM (mike knudsen) Newsgroups: comp.sys.m6809 Subject: Poisonous File Bug in Level 2 Message-ID: <1939@ihwpt.ATT.COM> Date: Thu, 27-Aug-87 13:58:31 EDT Article-I.D.: ihwpt.1939 Posted: Thu Aug 27 13:58:31 1987 Date-Received: Sat, 29-Aug-87 10:32:05 EDT Organization: AT&T Bell Laboratories - Naperville, Illinois Lines: 48 Keywords: funny files hang windows In the last couple of days, My Coco-3 Level 2 system has taken to creating "poison files." (I think my earlier reported c.asm bug may have been caused by a poisonous program.o file, tho I was able to LIST it.) The symptoms of a poison file are that any attempt to List or even Delete it will cause that window to hang. The disk stops turning, but you can't BREAK the task. You can't KILL it from another window because it still has I/O pending. The poisoned rogue task continues to soak up CPU cycles as evidenced by sparkles on other screens. Other windows can still do disk I/O normally. This shows that the hung code is not in a critical section of RBFMAN or CC3DISK. However, if asked to do something to that same file that hung the other window, your next window may hang too. COPYing a poisoned file tries for a while, makes sick twitching short moves of the disk head, then reports a read error. Usually does NOT hang. I noticed that DIR E reports poison files as being either 0 bytes long or many more bytes than they are (like 4000 Hex). One theory is that the disk directory, or the RBFMAN routines that handle it, have conflicting notions about the file's length; the sector map for that file runs out so RBFMAN refuses to deliver any more data to your task, but since the byte count is less than the phony length, RBFMAN refuses to issue an EOF to your task. I just hope my file system isn't corrupted; a DCHECK reported everything OK. A reboot so far has unpoisoned the file long enuf to delete or copy it. I don't know whether this is disk controller hardware problem, RAM upgrade, bit-rot in OS9, or a subtle bug. It usually doesn't happen till the system is pretty warm. Maybe I'll have to run Commo-64 style, with the Coco case top off. Or relocate that voltage regulator, stupidly buried in the worst-ventilated part of the case. BTW, the disk drive that gives me the most trouble does not have a head-load solenoid, so that's not the problem. Maybe the problem will disappear next week when my Sardis arrives. -- Mike J Knudsen ...ihnp4!ihwpt!knudsen Bell Labs(AT&T) Delphi: RAGTIMER CIS: "Just say NO to MS-DOS!"