[HACKERS] 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. signature.asc Description: Digital signature
Re: [HACKERS] Coverity reports looking good
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: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Coverity reports looking good
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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Coverity reports looking good
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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Coverity reports looking good
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: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Coverity reports looking good
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 -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | 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 bind them... http://mark.mielke.cc/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
