Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!tut.cis.ohio-state.edu!ucbvax!DMZRZU71.BITNET!Ritzert
From: Ritzert@DMZRZU71.BITNET
Newsgroups: comp.sys.atari.st
Subject: poolfix3
Message-ID: <900218230844.275515@DMZRZU71-UNI-MAINZ--GERMANY>
Date: 18 Feb 90 23:08:00 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 30

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.bitnet