djd1@csug.cs.reading.ac.uk (03/08/90)
Basically, does anybody know _exactly_ what it is? I am having some
problems with a program that I suspect may be due to the '40-Folder Bug',
but until I know what it is I cannot do anything about it.
Is it that you cannot have folders nested more than 40 deep, or that
a program (or process) cannot visit more than 40 folders??
ANY help would be appreciated here..
Cheers, Dave.
(P.S. Email me via address below, or better still, post an article. Thanks.)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
| David J. Dawkins | djd1%UK.AC.reading.cs.rosemary@uk.ac.nsfnet-relay |
| Reading University | |
| Berkshire | Uhh..Something prophetic,witty,disclamatory.. |
| United Kingdom | |
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-hcj@lzsc.ATT.COM (HC Johnson) (03/09/90)
In article <2105@onion.reading.ac.uk>, djd1@csug.cs.reading.ac.uk writes: > > Basically, does anybody know _exactly_ what it is? I am having some > problems with a program that I suspect may be due to the '40-Folder Bug', > but until I know what it is I cannot do anything about it. > > Is it that you cannot have folders nested more than 40 deep, or that > a program (or process) cannot visit more than 40 folders?? > TOS in ROMS (1.1 and 1.2) the 40-folder bug is caused from not cleaning up after VISITING 40 folders. It really screws up after that. TOS in EPROMS (1.4 aka 1.6) the 40-folder is a LIMIT on depth. You get a clean error message if you use up your folders. The fix for both is foldrnnn.prg from atari that adds nnn folders to the pool. p.s. the "40" comes from the floppy based systems. TOS 1.1 etc disk drivers usually added "100" more just to give you a fighting chance. So on a hard disk it was usually a 140 folder bug. TOS 1.4 does not have AHDI add the folders as it not necessary to boot successfully. Howard C. Johnson ATT Bell Labs att!lzsc!hcj hcj@lzsc.att.com
ignac@electro.UUCP (Ignac Kolenko) (03/11/90)
just a simple question: if the same foldrxxx.prg fixes both tos 1.0 and tos
1.4, why wasn't foldrxxx.prg put in the tos 1.4 roms at release time? makes
sense to me!
--
=====Ignac A. Kolenko (The Ig)=====watmath!watcgl!electro!brasoft!ignac======
co-author of QuickST, and the entire line of Quick Software!!!!
Branch Always Software Box 2624, Station B, Kitchener, Ont. CANADA N2H 6N2
=============================================================================cmm1@cunixa.cc.columbia.edu (Christopher M Mauritz) (03/11/90)
Ignac does have a point. If the entire world knew about the 40 folder bug from day one (ok, maybe day two), why didn't you techno-programmo- studs fix the thing in your subsequent 2 releases of TOS? If a few German hackers can come up with a kickass TOS substitute working in their spare time (GEMINI) while they study for exams, drink beer, and hang out with their girlfriends, why can't Atari's PAID programmers get these KNOWN bugs out after 4 years? This is hilarious. That is why my ST is sitting on my desk gathering dust and only getting occasional use as a DUMB terminal, rather than doing meaningful work for me. GRRRRR! <flame off> grin... Chris ------------------------------+--------------------------- Chris Mauritz |Where there's a BEER, cmm1@cunixa.cc.columbia.edu |there's a plan. (c)All rights reserved. | Send flames to /dev/null |Need I say more? ------------------------------+---------------------------
cmm1@cunixa.cc.columbia.edu (Christopher M Mauritz) (03/11/90)
------------------------------+--------------------------- Chris Mauritz |Where there's a BEER, cmm1@cunixa.cc.columbia.edu |there's a plan. (c)All rights reserved. | Send flames to /dev/null |Need I say more? ------------------------------+---------------------------
djd1@csug.cs.reading.ac.uk (03/13/90)
Firstly, thanks to everyone who replied to my request for info on the
40-Folder bug - I'll try reading the FAT instead of visiting each folder.
Now..from what I have read here recently, am I to understand that even the
lastest ROMs do not fix this pathetic bug?? _Surely_ a bug like this could have
easily been fixed (although I do not profess to know the 'ins and outs' of it),
and make the ST nearer to the perfect machine than it is already?
While on the subject of new ROMs, can anyone suggest a valid reason for
purchasing them, how much , where from etc? I apologise in advance if this
information has been posted before, but I don't get to read rn that often.
Cheers,
David.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
| David J. Dawkins | djd1%UK.AC.reading.cs.rosemary@uk.ac.nsfnet-relay |
| Reading University | |
| Berkshire | party, Party, PARTY, < P A R T Y > ! ! ! ! |
| United Kingdom | |
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-hcj@lzsc.ATT.COM (HC Johnson) (03/13/90)
In article <1990Mar10.174051.24717@cunixf.cc.columbia.edu>, cmm1@cunixa.cc.columbia.edu (Christopher M Mauritz) writes: > Ignac does have a point. If the entire world knew about the 40 folder > bug from day one (ok, maybe day two), why didn't you techno-programmo- > studs fix the thing in your subsequent 2 releases of TOS? > Come on fellas, it was fixed. You just don't understand. Before Tos 1.4, Every FOLDER that was touched counted as 1. If the limit was 40, then 40 touches and you started getting corruption and death. Tos 1.4 counts 1 for every FOLDER CURRENTLY OPEN. This is now a depth problem. And you get an error message if the limit is exceeded. Now only the USER knows how deep his folders are. FOLDRXXX allows the system to be TUNED to the users needs. After all, there is a price paid for large XXX, namely lost RAM for programs. Atari wins this one. You lose. Howard C. Johnson ATT Bell Labs att!lzsc!hcj hcj@lzsc.att.com
t68@nikhefh.nikhef.nl (Jos Vermaseren) (03/14/90)
In article <1404@lzsc.ATT.COM>, hcj@lzsc.ATT.COM (HC Johnson) writes: > In article <1990Mar10.174051.24717@cunixf.cc.columbia.edu>, cmm1@cunixa.cc.columbia.edu (Christopher M Mauritz) writes: > > Ignac does have a point. If the entire world knew about the 40 folder > > bug from day one (ok, maybe day two), why didn't you techno-programmo- > > studs fix the thing in your subsequent 2 releases of TOS? > > > Come on fellas, it was fixed. You just don't understand. > > Before Tos 1.4, Every FOLDER that was touched counted as 1. If the limit > was 40, then 40 touches and you started getting corruption and death. > > Tos 1.4 counts 1 for every FOLDER CURRENTLY OPEN. This is now a depth > problem. And you get an error message if the limit is exceeded. Now only > the USER knows how deep his folders are. FOLDRXXX allows the system to > be TUNED to the users needs. After all, there is a price paid for large > XXX, namely lost RAM for programs. > > Atari wins this one. You lose. Not quite. We have still had some problems here with TOS 1.4, necessitating the use of FOLDRXXX. FOLDRXXX also concerns the space available for Malloc headers. Atari has improved that now also but at a very bad cost. In one program I had Malloced more than 100 memory blocks of 16 Kbytes (clearly a Mega-ST). Then I released these blocks. After that the computer was for about half a minute nearly unusable, because the internal garbage collection in GEMDOS to set all the blocks straight `take some time'. So Atari has solved the problem only half. There are fewer bugs but it is still a very poor solution. Another question: How comes that on MS-DOS the floppy is so much faster (and noisier)? Jos Vermaseren
ljdickey@water.waterloo.edu (L.J.Dickey) (03/14/90)
In article <1404@lzsc.ATT.COM> hcj@lzsc.ATT.COM (HC Johnson) writes: > ... > >Before Tos 1.4, Every FOLDER that was touched counted as 1. If the limit >was 40, then 40 touches and you started getting corruption and death. > >Tos 1.4 counts 1 for every FOLDER CURRENTLY OPEN. This is now a depth >problem. And you get an error message if the limit is exceeded. Now only >the USER knows how deep his folders are. FOLDRXXX allows the system to >be TUNED to the users needs. After all, there is a price paid for large >XXX, namely lost RAM for programs. > >Atari wins this one. You lose. I have a slightly different perspective. With the fixes in in Rainbow TOS (1.4), we all win. -- Leroy J. Dickey, Faculty of Mathematics, University of Waterloo. ljdickey@water.UWaterloo.ca ljdickey@water.BITNET ljdickey@water.UUCP ..!uunet!watmath!water!ljdickey ljdickey@water.waterloo.edu
cmm1@cunixa.cc.columbia.edu (Christopher M Mauritz) (03/15/90)
Thanks for the reply, Howard. From Ignac's post, I assumed (get's you in trouble sometimes) that the bug was in its original annoying form. If, as you say, the "problem" has been made into one of limited depth then I guess for most users that is enough of a fix. Sorry if it seemed like I was being harsh. <blush> Chris ------------------------------+--------------------------- Chris Mauritz |Where there's a BEER, cmm1@cunixa.cc.columbia.edu |there's a plan. (c)All rights reserved. | Send flames to /dev/null |Need I say more? ------------------------------+---------------------------
gl8f@astsun.astro.Virginia.EDU (Greg Lindahl) (03/16/90)
In article <805@nikhefh.nikhef.nl> t68@nikhefh.nikhef.nl (Jos Vermaseren) writes: >In one program I had Malloced more than 100 memory blocks of 16 Kbytes >(clearly a Mega-ST). All the descriptions of Malloc() that I've ever seen include the information that you should not malloc more than 20 blocks per process. This is a fundamental limitation, and Atari never said they removed it. You should Malloc bigger blocks and then parcel out sub-blocks, see dLibs' malloc() for an example. PS Yes, Jos, I know you know this, I'm not trying to insult your intelligence. Greg Lindahl gl8f@virginia.edu Astrophysicists for Choice.
t68@nikhefh.nikhef.nl (Jos Vermaseren) (03/16/90)
In article <1990Mar15.160939.16350@murdoch.acc.Virginia.EDU>, gl8f@astsun.astro.Virginia.EDU (Greg Lindahl) writes: > > >In one program I had Malloced more than 100 memory blocks of 16 Kbytes > >(clearly a Mega-ST). > > All the descriptions of Malloc() that I've ever seen include the > information that you should not malloc more than 20 blocks per > process. This is a fundamental limitation, and Atari never said they > removed it. You should Malloc bigger blocks and then parcel out > sub-blocks, see dLibs' malloc() for an example. > In the days of youthful enthousiasm I disassembled and discompiled GEMDOS. It turns out that the OS-pool is a common area for all internal headers. They are sitting there in the order that they are needed. In the old version it was impossible to really return these blocks to the pool, and because these blocks have different sizes there would be a horrible mess and once you allocated a block for a malloc header it could only be used as such afterwards. There was room for a little over 200 malloc blocks or a little over 40 pairs of folder blocks (each folder needed two). So having more than 200 mallocs going at the same time would transform the 40 folder bug into a 2 folder bug (I tried this out once by running only on a floppy with a little program that did this type of malloccing). In TOS1.4 the blocks are returned to the pool (as far as I understand, because I haven't disassembled that one). This is a great improvement. In addition the folder blocks are released when they aren't needed anymore (that was the main part of the 40-folder bug). That I am greatful for. Apparently now the rule is to limit the malloc calls to 'not too many' because the mechanism that returns the blocks to the pool has rather poor behaviour in the limit that the number of malloc blocks is large. I found this experimentally because I had a large file in an editor, and after its garbage collections after a global replace were rather funny. So the first suspect was the editor. But on other systems it behaved properly, so this made GEMDOS suspect. The size of 16 Kbytes was taken with great care: If the blocks are too large there is inefficient use of memory when the last block is allocated. If they are too small you need too many of them. Other problem if they are too large: This size keeps the time of the tasks in the own garbage collections quite reasonable, so you never notice them at all. Problem with dynamic sizes: You need more code and it is slower. In micro computers you want too keep the size of your tools as small as possible.The 16K worked perfectly till the garbage collections of GEMDOS gave it some annoyance factor. This was what I was trying to explain, but I admit I was a little terse about it. Over the whole TOS 1.4 is a great improvement, but I believe there is still room for a TOS 2.0 Jos Vermaseren
fischer-michael@CS.YALE.EDU (Michael Fischer) (03/16/90)
In article <1482@electro.UUCP> ignac@electro.UUCP (Ignac Kolenko) writes: > > >just a simple question: if the same foldrxxx.prg fixe both tos 1.0 and tos >1.4, why wasn't foldrxxx.prg put in the tos 1.4 roms at release time? makes >sense to me! > The so-called 40-folder "bug", which caused TOS to waste memory in its static memory pool and to misbehave when that pool was exhausted, *was* fixed in TOS 1.4. But the pool is still statically allocated, and you can still run out of TOS memory. foldrxxx.prg doesn't "fix" anything. It simply lets you increase the size of that pool. In TOS 1.0 this lessens the chance that the "bug" will bite. In TOS 1.4 it lessens the chance that TOS will run out of its private memory. ================================================== | Michael Fischer | | Arpanet: <fischer-michael@cs.yale.edu> | | Bitnet: <fischer-michael@yalecs.bitnet> | | UUCP: <fischer-michael@yale.UUCP> | ==================================================