Re: Memory leak in GNU readline (?)

jab3 wrote:

Not sure if this is the right place to post this, but figured someone here
could either point out my error, or lead me in the right direction. From
what I can tell, there is a memory leak with the GNU readline function.
(5.0) When the following example program is run under valgrind (maybe the
problem is with valgrind, but I doubt it), I get this error:

==9806== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 22 from 4)
==9806== malloc/free: in use at exit: 146674 bytes in 256 blocks.
==9806== malloc/free: 615 allocs, 359 frees, 163804 bytes allocated.
==9806== For counts of detected errors, rerun with: -v
==9806== searching for pointers to 256 not-freed blocks.
==9806== checked 306288 bytes.
==9806==
==9806== LEAK SUMMARY:
==9806== definitely lost: 40 bytes in 2 blocks.
==9806== possibly lost: 0 bytes in 0 blocks.
==9806== still reachable: 146634 bytes in 254 blocks.
==9806== suppressed: 0 bytes in 0 blocks.
==9806== Use --leak-check=full to see details of leaked memory.

That output can just about be obtained by running the program through
valgrind and typing 'exit' (or even Ctrl-C).

Is the C runtime given the opportunity to perform all required clean-ups
when your process gets terminated by SIGINT? (I think file descriptors
are not properly closed, for example.)

Do you get the same leak summary if you export GLIBCXX_FORCE_NEW before
you run the program?

Regards.
.

Relevant Pages