Ritzert@DMZRZU71.BITNET (02/19/90)
well, we have a program that triggers the tos1.4 pool bug. It is the
universal TeX screen/printer driver by tools GmbH, Bonn (version 1.1w).
The program probably does a lot of mallocs (or Mallocs?). The error
appears when You close the first dvi file and start printing a second
one without leaving dvi.prg. When I leave dvi.prg and start it anew, no
problems...
In order to cure this bug i put poolfix3 into the auto folder (as the
last program). Nothing changed. Then I reordered the auto folder and put
poolfix3 into the first place. Result: the performance of dvi.prg
slightly improved. Now we can look at 3-5 dvi files without system halt.
The program worked without any problems under tos1.2 and even with
tos1.2/turbodos1.05 for a long time. The fastload bit is not set.
So i conclude, that
a) dvi.prg may contain a bug which triggers the problem.
b) even poolfix3 does not completly cure the memory pool bug.
Question to Allan or Ken:
Shall I install folder100 in addition? Before or after poolfix3?
Or shall I install ONLY folder100 to slove this problem?
BTW, i just ordered an update to the software. The people at tools were
not aware of this problem, so I think the present software will not
behave better.
regards,
Michael Ritzert
mjr@dmzrzu71.bitnetapratt@atari.UUCP (Allan Pratt) (02/21/90)
Ritzert@DMZRZU71.BITNET writes: >[We have a program which dies; poolfix3 improves it a little.] >Question to Allan or Ken: > Shall I install folder100 in addition [to poolfix3]? You should certainly use foldr100. Poolfix3 only fixes a bug in the code which manages GEMDOS's internal memory. You can still run OUT of memory there, and FOLDR100.PRG adds more. A program which uses Malloc() a lot, or has lots of open files at the same time, can use up all this memory. If you see the "panic" message, it's USUALLY because you ran out of pool memory. Using poolfix3 will not change this. Using FOLDR100 will. Poolfix3 should print a message when it runs; that message either says it was INSTALLED or says there was some error. The most common error is that it can't find GEMDOS: if some program has run earlier in the AUTO folder and swiped the GEMDOS trap, that'll do it. (Other messages include detecting that your GEMDOS doesn't need poolfix at all, and that your GEMDOS *does* need poolfix, but it can't be installed for some reason. That one should "never happen.") ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
jimh@ultra.com (Jim Hurley) (02/23/90)
apratt@atari.UUCP (Allan Pratt) writes: >Ritzert@DMZRZU71.BITNET writes: >>[We have a program which dies; poolfix3 improves it a little.] >>Question to Allan or Ken: >> Shall I install folder100 in addition [to poolfix3]? >You should certainly use foldr100. Poolfix3 only fixes a bug in >the code which manages GEMDOS's internal memory. You can still >run OUT of memory there, and FOLDR100.PRG adds more. A program >which uses Malloc() a lot, or has lots of open files at the same >time, can use up all this memory. Could you please elaborate? I thought TOS 1.4 fixed the folder problem. Should one *always* use FOLDRXXX? Actually, although I've heard a lot about this bug, I've never read a consistent description of the problem. -- Jim Hurley --> jimh@ultra.com ...!ames!ultra!jimh (408) 922-0100 Ultra Network Technologies / 101 Daggett Drive / San Jose CA 95134
fischer-michael@CS.YALE.EDU (Michael Fischer) (02/24/90)
In article <1990Feb22.195715.1132@ultra.com> jimh@ultra.com (Jim Hurley) writes: >apratt@atari.UUCP (Allan Pratt) writes: > >>Ritzert@DMZRZU71.BITNET writes: > >>>[We have a program which dies; poolfix3 improves it a little.] >>>Question to Allan or Ken: >>> Shall I install folder100 in addition [to poolfix3]? > >>You should certainly use foldr100. Poolfix3 only fixes a bug in >>the code which manages GEMDOS's internal memory. You can still >>run OUT of memory there, and FOLDR100.PRG adds more. A program >>which uses Malloc() a lot, or has lots of open files at the same >>time, can use up all this memory. > >Could you please elaborate? I thought TOS 1.4 fixed the >folder problem. Should one *always* use FOLDRXXX? > >Actually, although I've heard a lot about this bug, I've never >read a consistent description of the problem. Here's my understanding of things: TOS needs memory for various internal things which it takes from a memory pool of FIXED SIZE. When memory is no longer needed, it is returned to the pool for later reuse. FOLDRXXX allows you to increase the size of the pool, and POOLFIX3.PRG fixes a TOS 1.4 bug in the management of that memory. Even with both programs, it is possible to run out of memory, especially if you do a lot of Malloc's, but obviously, the bigger the pool, the less likely you are to run out. TOS 1.0 and 1.2 used the memory less wisely and had varous bugs in the management of the pool that could cause the machine to crash. In particular, it failed to check properly when the pool was exhausted, so when too many folders or too many Malloc's used up the pool, weird things would start happening. The so-called "40-folder" limit was just an empirical observation that users who had at most 40 folders on their disks were unlikely to exhaust memory. Thus, as long as one had at most 40 folders, the problem would not usually be encountered. By increasing the size of the pool, FOLDRXXX allowed more folders to be used. Allan Pratt put a lot of effort into cleaning this up in TOS 1.4. [Thanks, Allan!] You are now much less likely to run out of memory, and crashes shouldn't happen. In particular, inactive folders no longer use memory, so you can have a large number of folders on your disk without needing to increase the size of the pool. However, you still can run out of internal memory and you may well need to use FOLDRXXX to increase the size. If you do run out, the system stops with an "out of internal memory" message and suggests that you increase the size of the pool. ================================================== | Michael Fischer | | Arpanet: <fischer-michael@cs.yale.edu> | | Bitnet: <fischer-michael@yalecs.bitnet> | | UUCP: <fischer-michael@yale.UUCP> | ==================================================
qralph@dna.lth.se (Ralph Haglund) (02/24/90)
This question is actually directed to Alan Pratt, but as he never answers my direct e-mail I will send it on the net: I have heard that TOS 1.4 is available for users in Sweden now -I don't know details. Anyway: as official developer I have been begging for it for half a year now from Atari Sweden, never got anything at all. The Swedish TOS, both 1.2 and 1.4 as far as I know, has had a bug when it comes to the scan codes, the shift+arros and shift+Ins/Home has just given 0; I sent the patches for that for 1.4 to Atari, Stockholm after they wanted it during a telephone call. Never heard from them after that so no idea if they have incorporated it. Besides, in the EPROMs I have incorporated 5 well-known and -documented German patches, like fixing the serial port etc. Now I got a problem. Lots of people want my patched EPROMs. They want to be able to use editors like First word + (where obviously the shift-arrows never worked), they want to use fast modems on the serial port etc. What do I do????? Do I tell them it is illegal according to Atari to have a working Atari ST or what????????? |-------------------------------------------------------------| | Want to talk to me? Try: | | QRALPH@SELDC51 || QRALPH@SELDC52 || qralph@dna.lth.se | | My name? In official Sweden it is: 4.901.185.654 (secret) | | Anywhere else: Ralph Haglund | | Disclaimer: If it works, it's out of date. | |_____________________________________________________________|
UJ0A@DKAUNI2.BITNET ("Rainer Seitel") (02/24/90)
Allan Pratt writes: > Poolfix3 should print a message when it runs; that message either says > it was INSTALLED or says there was some error. The most common error > is that it can't find GEMDOS: if some program has run earlier in the > AUTO folder and swiped the GEMDOS trap, that'll do it. (Other messages > include detecting that your GEMDOS doesn't need poolfix at all, and > that your GEMDOS *does* need poolfix, but it can't be installed for > some reason. That one should "never happen.") That message happen to a friend. But I believe that's because I've patched his Rainbow-TOS for the 68020. The TOS14FIX also doesn't work (because of Line F). This doesn't matter because I'd included this patch. Now I'm not sure if FOLDERxxx works after including the poolfix patch. Which way do FOLDERxxx add memory to the pool in Rainbow TOS? Rainer ---------------------------------------------------------------------- Rainer Seitel EMAIL: UJ0A@DKAUNI2.BITNET Zaystrasse 13 D-7550 Rastatt
apratt@atari.UUCP (Allan Pratt) (02/24/90)
jimh@ultra.com (Jim Hurley) writes: >Actually, although I've heard a lot about this bug, I've never >read a consistent description of the problem. The TOS 1.4 release notes describe the problem completely and in loving detail. As a rule, YOU DON'T NEED TO KNOW, which is why I don't spend my days posting long explanations here. What you DO need to know is this: 1. If you have Mega TOS or Original TOS (1.2 or 1.0) and a hard disk, you should use FOLDR100.PRG. Without it, the system starts screwing up when you've visited (or even just brushed by) 40 folders or so. 2. If you have Rainbow TOS or STe TOS (1.4 or 1.6), YOU DEFINITELY NEED POOLFIX3.PRG! (2a. STe TOS is just like Rainbow TOS in almost every respect; it isn't an "enhancement" and you shouldn't wait for it to come out for the ST. It's just Rainbow TOS with modifications to make it run the STe.) 3. If you have Rainbow TOS or STe TOS you MIGHT want to use FOLDR100.PRG. The management of the internal memory (which FOLDR100.PRG adds to) is greatly improved, but you can still run out. It's no longer a question of how many folders you've "seen" but rather of how many folders and files are ACTIVE, which is to say, in use at any one time. Most people don't open a file 40 directories down in their heirarchy, or two folders each 20 (different) levels down, or whatever. 4. If the system ever locks up and tells you to use FOLDR100.PRG, then you probably should. In short, POOLFIX3 actually fixes a bug which every Rainbow TOS user is exposed to; FOLDR100.PRG adds memory to an internal pool. That internal pool is really badly managed in pre-Rainbow TOSes, and much much better managed in Rainbow TOS (after you fix the bug by running POOLFIX3), but in both cases you benefit by using FOLDR100. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt "This is an egg, this is a skillet, and THIS is breakfast. Any questions?"
aimd@castle.ed.ac.uk (M Davidson) (02/26/90)
In article <16819@cs.yale.edu> fischer-michael@CS.YALE.EDU (Michael Fischer) writes: [Micheal writes about the 40-folder bug]... >TOS 1.0 and 1.2 used the memory less wisely and had varous bugs in the >management of the pool that could cause the machine to crash. In >particular, it failed to check properly when the pool was exhausted, >so when too many folders or too many Malloc's used up the pool, weird >things would start happening. The so-called "40-folder" limit was >just an empirical observation that users who had at most 40 folders on >their disks were unlikely to exhaust memory. Thus, as long as one had >at most 40 folders, the problem would not usually be encountered. By >increasing the size of the pool, FOLDRXXX allowed more folders to be >used. I have just got a Hard Drive after 3 months of waiting for Power Computing to come up with it (just thought I'd add that dig). Now that I have all this disk space the 40-folder bug must be more likely. Can someone explain exactly what causes the memory to be used up. Is it creating folders/opening folders or both? I have installed foldr100 but I'd like to have some sort of empirical measure of how long I can muck around with my drive (setting it up etc.) before I should reboot. Also, what are the symptoms of the bug? Does the machine crash or would things like having several copies of the one file (with the same name) in the same directory be a possible consequence? This happened to me last night but I wouldn't like to jump to conclusions - I'd been compiling a C prog which refused to do anything but bomb out, but my ST kept on going (it didn't lock up) so normally I would have thought that was the cause. While I'm on the subject, what does *one* bomb mean? Neodesk didn't know and either did any of my books.... >| Michael Fischer | >| Arpanet: <fischer-michael@cs.yale.edu> |
george@electro.UUCP (George Reimer) (02/27/90)
In article <"90-02-23-11:37:20.38*UJ0A"@DKAUNI2.BITNET> UJ0A@DKAUNI2.BITNET ("Rainer Seitel") writes: >That message happen to a friend. But I believe that's because I've >patched his Rainbow-TOS for the 68020.... > > Rainer Could you please tell us more about this upgrade? How much effort did it take to make the patches? How compatible is your software? Did you install your own 020? -- "I almost think that in certain cases yes, and in others, no....." George egroeG Reimer remieR
ljdickey@water.waterloo.edu (L.J.Dickey) (02/28/90)
In article <2470@castle.ed.ac.uk> aimd@castle.ed.ac.uk (M Davidson) writes: | ... | I have just got a Hard Drive ... | Now that I | have all this disk space the 40-folder bug must be more likely. | | Can someone explain exactly what causes the memory to be used up. Is it | creating folders/opening folders or both? I have installed foldr100 but | I'd like to have some sort of empirical measure of how long I can muck | around with my drive (setting it up etc.) before I should reboot. It is the number of directories (folders) you visit during a session that counts. I think you will be safe if you set "XXX" in FOLDRXXX to be a number greater than the total number of directories on your disks. | Also, what are the symptoms of the bug? Does the machine crash or would | things like having several copies of the one file (with the same name) in | the same directory be a possible consequence? This is a problem in the operating system; but don't know if this is one of the symptoms of the 40 folder bug. I would be surprised if it is. Maybe someone else can shed some light on this point. -- L. 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
apratt@atari.UUCP (Allan Pratt) (03/01/90)
ljdickey@water.waterloo.edu (L.J.Dickey) writes: >In article <2470@castle.ed.ac.uk> aimd@castle.ed.ac.uk (M Davidson) writes: > | I'd like to have some sort of empirical measure of how long I can muck > | around with my drive (setting it up etc.) before I should reboot. >It is the number of directories (folders) you visit during a session >that counts. I think you will be safe if you set "XXX" in FOLDRXXX >to be a number greater than the total number of directories on your >disks. That's true for Original TOS and Mega TOS. For Rainbow TOS (TOS 1.4), XXX need only be the number of folders you'll have "active" at once. "Active" folders are those involved in file searches, open files, etc. If you open a file, the folder it's in and all the parents of that folder are "active;" if you open another file in the same directory, you haven't increased the number of active folders. If you close both files, those folders aren't "active" any more, and the space they took up in the pool will be reused when necessary. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt