Thread: Coverity reports looking good
I thought I'd like to report that right now the Coverity reports are looking good. There are no issues detected in either the backend code or the ECPG library. For the latter I'd like the thank Joachim Wieland and Michael Meskes for getting ECPG into shape. Whats basically left is a large number of memory leaks in frontend applications such as pg_dump, initdb, pg_ctl, etc. These haven't ever really been a priority (buildACLCommands is really bad in this respect). Some examples can be found here: http://svana.org/kleptog/temp/pgsql-bin.xml If someone wants to make a serious attempt at tackling them, I can provide an updated list. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
On Sun, Aug 20, 2006 at 03:49:24PM +0200, Martijn van Oosterhout wrote: > Whats basically left is a large number of memory leaks in frontend > applications such as pg_dump, initdb, pg_ctl, etc. These haven't ever > really been a priority (buildACLCommands is really bad in this > respect). > ... > If someone wants to make a serious attempt at tackling them, I can > provide an updated list. If my time permits I'm willing to look into these a little bit as I now know a little bit about Coverity reports. And since I found that these reports not only show potential memory leaks (which I don't worry about much in short lived frontend apps) they sometimes point to bugs that may cause real problems. I just had a small look at one in pg_dump.c. However, it seems the line numbers are completely different from my CVS snapshot. Are the Coverity reports you listed up-to-date? Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Martijn van Oosterhout <kleptog@svana.org> writes:
> Whats basically left is a large number of memory leaks in frontend
> applications such as pg_dump, initdb, pg_ctl, etc. These haven't ever
> really been a priority (buildACLCommands is really bad in this
> respect).
Well, if Coverity's idea of good programming practice is that every
program must explicitly free everything it ever malloced before it
terminates, then I'm afraid we'll have to agree to disagree. The
above is nothing but make-work as far as programs with short intended
runtimes go. A leak in psql would be interesting if it can accumulate
across command-execution cycles, but I have zero interest in "cleaning
up" any of the programs mentioned above.
regards, tom lane
Martijn van Oosterhout wrote: > I thought I'd like to report that right now the Coverity reports are > looking good. There are no issues detected in either the backend code > or the ECPG library. For the latter I'd like the thank Joachim Wieland > and Michael Meskes for getting ECPG into shape. > > Whats basically left is a large number of memory leaks in frontend > applications such as pg_dump, initdb, pg_ctl, etc. These haven't ever > really been a priority (buildACLCommands is really bad in this > respect). > > Some examples can be found here: > http://svana.org/kleptog/temp/pgsql-bin.xml > > If someone wants to make a serious attempt at tackling them, I can > provide an updated list. > > > At least in the case of initdb, when I was coding it I was perfectly well aware that there would be memory leaks - and the code contains a comment to the effect that cleaning them up isn't worth the trouble. I think we can be more liberal in programs that are not long-lived and won't continue to leak more and more memory. cheers andrew
On Sun, Aug 20, 2006 at 11:52:53AM -0400, Tom Lane wrote: > Well, if Coverity's idea of good programming practice is that every > program must explicitly free everything it ever malloced before it > terminates, then I'm afraid we'll have to agree to disagree. The I don't think Coverity even knows how long a program may run. But while I agree that freeing all memory is not needed in a short running program, I still think we should examine those reports because they may show some real bugs. At least this is what happened to some degree in ecpg. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: meskes@jabber.org Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
On Sun, Aug 20, 2006 at 11:52:53AM -0400, Tom Lane wrote:
> Martijn van Oosterhout <kleptog@svana.org> writes:
> > Whats basically left is a large number of memory leaks in frontend
> > applications such as pg_dump, initdb, pg_ctl, etc. These haven't ever
> > really been a priority (buildACLCommands is really bad in this
> > respect).
> Well, if Coverity's idea of good programming practice is that every
> program must explicitly free everything it ever malloced before it
> terminates, then I'm afraid we'll have to agree to disagree. The
> above is nothing but make-work as far as programs with short intended
> runtimes go. A leak in psql would be interesting if it can accumulate
> across command-execution cycles, but I have zero interest in "cleaning
> up" any of the programs mentioned above.
Each of the reported issues should be investigated, for however short, to
see whether it is intentional or not.
For example, if the memory is allocated within a loop, or which the bounds
are not fixed, even a short running program can benefit from being fixed.
If it is just configuration data represented in memory, created once,
who cares... :-)
Cheers,
mark
--
mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness
bindthem...
http://mark.mielke.cc/