mann@intacc.uucp (Jeff Mann) (09/09/90)
My relaynews, which has been running just fine for many months, has suddenly started to act strangely. Every batch fails with status 1, and in errlog I find: relaynews: out of memory (not a typewriter), once for each batch. This has been happening for about a month now, but since it seemed like most or all of the articles were being installed ok anyways, I have just ignored it. However, expire is now complaining about running out of memory in various functions, and I can't very well do without expire. Both programs are compiled small model on a 286 machine, and I have not re-compiled them or changed any configuration that I can think of. RE-building the history file has no effect. All other programs on the system are acting normally. A test program I wrote is able to malloc 53k in 1k blocks; is there any reason that this would be insufficient for either of these programs? Should I re-compile them in large model? Any suggestions on a strategy to figure this problem out would be greatly appreciated... -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Jeff Mann ...uunet!mnetor!intacc!mann mann@intacc.uucp | | Inter/Access Artists' Centre - Matrix Artists' Network [416]535-8601 | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
henry@zoo.toronto.edu (Henry Spencer) (09/10/90)
In article <1990Sep8.203418.1763@intacc.uucp> mann@intacc.UUCP (Jeff Mann) writes: >... However, expire is now complaining about >running out of memory in various functions, and I can't very well >do without expire. Expire, unfortunately, tries to swallow the entire active file, so its need for space has been growing steadily as the number of newsgroups has grown. Sounds like it's gone over the edge. I have sketched out a fix for this but have not done it yet. I assume you answered "small" to the build question about available address space. Given that, relaynews doesn't have a similar problem that I know of, but it may be just on the edge. We unfortunately have not had a 16-bit machine on hand for development testing for quite some time, and this makes it difficult to keep tabs on whether things still fit. I fear that recompiling using large model is the answer. -- TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology OSI: handling yesterday's loads someday| henry@zoo.toronto.edu utzoo!henry
mann@intacc.uucp (Jeff Mann) (09/13/90)
In article <1990Sep9.224002.17588@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >In article <1990Sep8.203418.1763@intacc.uucp> mann@intacc.UUCP (Jeff Mann) writes: >>... However, expire is now complaining about >>running out of memory in various functions, and I can't very well >>do without expire. > >I fear that recompiling using large model is the answer. >-- >TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology >OSI: handling yesterday's loads someday| henry@zoo.toronto.edu utzoo!henry Right you were. I re-compiled expire and relaynews in large model and besides my Microport compiler choking on the nnafree macro in news.h (is there a fix for this? I'm not quite up to date on the patches) both programs are now working perfectly again. The problem in relaynews seemed to be related to unbatching; along with the "out of memory" messages in the errlog were an unusually large number of "unbatcher out of sync" messages. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Jeff Mann ...uunet!mnetor!intacc!mann mann@intacc.uucp | | Inter/Access Artists' Centre - Matrix Artists' Network [416]535-8601 | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
henry@zoo.toronto.edu (Henry Spencer) (09/13/90)
In article <1990Sep12.170526.10791@intacc.uucp> mann@intacc.UUCP (Jeff Mann) writes: >...besides my Microport compiler choking on the nnafree macro in news.h >(is there a fix for this? ... See notebook/problems; others have had this problem. We consider it a compiler bug and decline to fix it, but notebook/problems documents some possibly-useful workarounds. -- TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology OSI: handling yesterday's loads someday| henry@zoo.toronto.edu utzoo!henry