Re: BUG #4496: Memory leak in pg_dump.c?

On Thursday 30 October 2008, Tomáš Szépe wrote:

> > A pg_dump run is comparatively short-lived, so if Zdenek is right then
> > there's no important leak here -- we're counting on program exit to
> > release the memory. There's probably little point in releasing things
> > earlier than that.
>
> Well, I'd tend to consider any logical part of a program that fails to
> release the memory it uses to be bad coding practice. You never know
> when you're going to need to shuffle things around, change the context
> of the code in a way that makes it long-lived, in turn causing the leak
> to become a real problem. Also, don't you like seeing the free()s paired
> to their mallocs()s in a way that makes the allocations intuitively
> correct? :)

Unfreed memory is not the same as leaked memory. Leaked memory is unfreed
memory which should have been freed. Sometimes it's best not to do it. If
done it purposefully some times. Once I had to build a HUGE tree of data just
to print some reports. I alloced the nodes ( by carving small chunks from big
malloced blocks, but this was an optimization ) incrementally, finished
input, wrote output and just exit(), because I knew the OS will free the
memory, and keeping track of all the malloced blocks just to free them before
exiting to the OS is just wasting memory, and freeing them wastes time. The
OS guarantees on freeing memory, closing files and other autmoatic resource
releasing are there to be used when needed. Similarly nearly nobody bothers
to fclose() stdin/out/err or close 0/1/2, the OS will do it if needed. And
many malloc implementations grow the data segment using sbrk(), but don't
reduce it to the minimum when exiting to the OS.

Francisco Olarte.