canada@crash.cts.com (Diane Barlow Close) (12/11/89)
The following message appeared on the San Diego Atari Computer Enthusiast's
BBS. The originator of the message is quite a competent
programmer/developer for the ST, so I gave his message more ``weight'' than
if just anyone had posted it. Can anyone confirm or dismiss this bug
report:
Message : 974 [Open] 12-10-89 12:01am
From : John Sudikatus
To : All
Subject : TOS 1.4 bugs
Sig(s) : 1 (General news)
A WARNING TO ALL TOS 1.4 USERS!!!
Despite what Atari has said about the 40 folder bug being fixed in TOS
1.4, IT ISN'T! Actually, the "40 folder" problem in previous
versions of TOS may have indeed been fixed, but in reducing the amount
of low memory used by TOS (in attempt to be more compatible with TOS
1.0) another bug was introduced. It seems that the directory buffers
now overlap slightly with the dynamic memory pointer list. This means
that when you have accessed more than about 35 folders and then try to
allocate memory, there is a good chance that the program will bomb
horribly. This is most likely to occur in programs that search all
subdirectories on your disk (like a utility I wrote does).
I STRONGLY recommend using FOLDRXXX.PRG or CACHENNN.PRG in your AUTO
folder. FOLDRXXX.PRG seems to work since the added buffers are put at
the head of the list, meaning that they will be used before the
original 40 (80 actually, since each folder requires 2 buffers). But
one thing to note is that the size of disk buffers in TOS 1.4 has
increased slightly over that of TOS 1.0 & 1.2. To get the requested
number of buffers you must multiply the number of extra folders you
want by about 1.06 (70/66 to be exact) and rename FOLDRXXX with that
number.
Fix a bug, create a bug. That's Atari for you. Oh, well....
--
Diane Barlow Close
{nosc, ucsd}!crash!canada
canada@crash.cts.com
Free Canada -- Trade Mulroneyhcj@lzaz.ATT.COM (HC Johnson) (12/12/89)
> > A WARNING TO ALL TOS 1.4 USERS!!! > > Despite what Atari has said about the 40 folder bug being fixed in TOS > 1.4, IT ISN'T! Actually, the "40 folder" problem in previous > versions of TOS may have indeed been fixed, but in reducing the amount > > I STRONGLY recommend using FOLDRXXX.PRG or CACHENNN.PRG in your AUTO > folder. FOLDRXXX.PRG seems to work since the added buffers are put at > > Fix a bug, create a bug. That's Atari for you. Oh, well.... > -- > Diane Barlow Close > {nosc, ucsd}!crash!canada > canada@crash.cts.com > Free Canada -- Trade Mulroney Diane, ATARI has stated from the beginning the 40 folder bug was being reduced to levels of improbability, not removed. Further, in the Developer docs (I know, you didn't buy them; I did) it further states that lots of recursion in subdirectoried will definitely require using FOLDRXXX.PRG. Someone once said that any program larger than a page is never fully debugged. I'm sure that there still reside bugs with TOS 1.4, but its reality, not the "ATARI" syndrom that will cause them. Howard C. Johnson ATT Bell Labs att!lzaz!hcj hcj@lzaz.att.com
matthews@umd5.umd.edu (Mike Matthews) (12/12/89)
In article <876@crash.cts.com> canada@crash.cts.com (Diane Barlow Close) writes: > >The following message appeared on the San Diego Atari Computer Enthusiast's >BBS. The originator of the message is quite a competent >programmer/developer for the ST, so I gave his message more ``weight'' than >if just anyone had posted it. Can anyone confirm or dismiss this bug >report: > [ message about TOS 1.4 bug deleted ] >Diane Barlow Close Well.. TOS 1.4 *did* crash on me once, when I tried to access a folder (not sure of how many I had accessed before). I at the time had cachexxx, and now I have foldrxxx (foldr100 to be exact), and haven't had the problem happen since. Mike
rwa@cs.AthabascaU.CA (Ross Alexander) (12/16/89)
canada@crash.cts.com (Diane Barlow Close) writes: >From : John Sudikatus >A WARNING TO ALL TOS 1.4 USERS!!! [message precis: "perhaps the 40-folder bug is back in a new guise"] >1.0) another bug was introduced. It seems that the directory buffers >now overlap slightly with the dynamic memory pointer list. This means >that when you have accessed more than about 35 folders and then try to >allocate memory, there is a good chance that the program will bomb >horribly. This note is not a flame, but a request for information and also a data point for those debugging: Bug: zoo.ttp, arc521.ttp die horribly under suspicious circumstances. Environment: 1040 expanded to 2.5Mbytes, TOS 1.4 of 6 April 1989 in ROMs, Supra adapter & boot software rev 3.41 (? sorry, its @ home), Quantum Pro80 scsi drive, partition C is 32 Mbytes and contains 195 directories and 1700 files (+/- 5%). Running CACHE256.PRG in AUTO\, but not FOLDRnnn.PRG. Have a blitter. Running CONTROL.ACC, no other .ACC's; 200 Kbyte ram drive on H: (EDISK.PRG). Repeat-by: from desktop, run menu File/Info against drive C icon. Reports indicates 6.1 Mbytes free on C:; invoke Marc Williams Co MSH.PRG (version 3) to obtain shell, run MF.TOS (a utility of mine own creation :-) and observe 1.9 Mbytes free RAM. Then cd off to a directory 4 levels down (c:\arch\utl\src\emacs3v9) and run 'zoo aM emacs.zoo *'. Zoo runs along nicely for about 8 files and then reports 'file baz: read error' or 'input error on baz' or something along those lines. Cat'ing the file to stdout shows no problems. Rerunning zoo gets the same error at the same place again. Running 'arc521 a emacs.arc *' gets a 'write error: no space on disk??' at a different file, which again cat's out in a normal fashion, and again the fault is consistent and reproducable; there is still 5.5 Mbytes free on the partition according to DF.PRG. This general pattern could be repeated in many different directories; the Supra utilities report the disk is error free. Workaround-by: I ended up using gnutar and compress. No problems ever. Hope someone can make something of this. My suspicion: gnutar does lots of I/O but only allocates a little memory. Compress allocates one largish (~500k) chunk before it starts doing I/O, but none thereafter. Am I correct in guessing that zoo and arc tend to allocate and release memory in a fairly dynamic fashion while doing large amounts of I/O concurrently? According to the posted bug report, this would tend to excercize the buffer-pool vs. free-list collision bug... or so I surmise. Help? Ross