In my [humble] opinion, I think it would be somewhat useless to simply
receive purify output without being able to test the fix on a spot.
However, if/when all memory problems with postgres are fixed, this is what
probably should be done: every night when new snapshots are generated, a
cron job should recompile every executable (psql, postgres, etc.) with
purify, and execute the regression tests. The results could be posted
somewhere maybe in ftp.postgresql.org/VERSION/Purify/date.tar.gz
whatever the version and date are....
I I am also trying to evaluate a software package called Insight++ -
it is similar to Purify but supposed to check for a greater range of
memory errors and it runs on Digital Unix (which is the only machine on
which I don't have a quota...and postgres compiling can take alot of disk
space...)
=+=------------------------/\---------------------------------=+=
Igor Natanzon |**| E-mail: igor@sba.miami.edu
=+=------------------------\/---------------------------------=+=
On Wed, 4 Jun 1997, Thomas G. Lockhart wrote:
> Robert Withrow wrote:
> >
> > So, do you want me to start doing the purify runs every night?
> > If so, I still need to be able to build without user intervention...
> > Preferably without using expect... ;-)
>
> Hello Robert. I'm not familiar with Purify but I suspect that regular
> runs of Purify will be _extremely_ useful, but most so _after_ someone
> has started addressing the existing memory leaks and uninitialized
> reads.
>
> Igor has made several productive fixes in the frontend code but does not
> have time at the moment to look at the backend code, and I am still
> painfully ignorant on how to proceed with the output Robert sent to me.
>
> Igor, is a Purify output listing sufficient to track down and fix memory
> leak problems, or would it be most useful as a check to see that we
> haven't introduced new problems in the future? What is the procedure you
> use to identify and fix problems? Could you recommend a procedure which
> would allow Robert to run Purify but allow others to debug the code, or
> do you think it would be too cumbersome to work without having direct
> access to Purify?
>
> One concern I have is that we should be able to try to fix existing
> leaks and test them in Purify _before_ committing them to the source
> tree, otherwise we are likely to have a bunch of less-than-useful
> intermediate versions committed into CVS.
>
> Anyone have opinions/suggestions?
>
> - Tom
>
------------------------------