Xref: utzoo comp.sys.atari.st:34708 comp.sys.atari.st.tech:1330 Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!mcsun!hp4nl!utrcu1!mi.eltn.utwente.nl!klamer From: klamer@mi.eltn.utwente.nl (Klamer Schutte -- Universiteit Twente) Newsgroups: comp.sys.atari.st,comp.sys.atari.st.tech Subject: tos bug Was: Using GDB Message-ID: Date: 7 Feb 91 08:18:09 GMT References: <1991Feb1.170826.791@rodan.acs.syr.edu> <1991Feb5.124207.11850@doe.utoronto.ca> Sender: news@utrcu1.UUCP Lines: 27 david@doe.utoronto.ca (David Megginson) writes: >>BTW, when GCC compiling under gulam, "make" seems to 2-bomb out after some >>arbitrary period of happy mass compilation, ditto Ksh but less frequently. >>Under Ksh, problem seems to go away after the third/fourth round of mass >>compilation (with -g, without -g, with -gg, without -gg, ad nauseam) but return >>after a warm boot. Anyone shed any light on this --- I have a suspicion that >>it's a malloc() problem, but it's outside my field. >> >Aha! I suspect the 40-folder limit. You should be able to find a fix >for it on your local BBS. If you already have foldrxxx.prg (or whatever >it's called) installed, raise the number. Having experienced similar problems as described above using TeX ;-( i came to the conclusion that it was memory management, not the 40-folder limit (foldr200.prg didn't help; shuffling memory did sometimes. also the available memory sometimes came down to a whopping 10k -- not enough for TeX (I am stymied)). My solution to this "feature": use tos 1.4. I am now running without foldrxxx.prg && cache020.prg and have not experienced the problem. Klamer -- Klamer Schutte Faculty of electrical engineering -- University of Twente, The Netherlands klamer@mi.eltn.utwente.nl {backbone}!mcsun!mi.eltn.utwente.nl!klamer