Re: memory leak?

[Daniel J S. <dan...@ie...>]

OK, valgrind has isolated a couple leaks in the pipe works (patch attached):

==10516==
==10516== ERROR SUMMARY: 137 errors from 11 contexts (suppressed: 27 from 1)
==10516== malloc/free: in use at exit: 144724 bytes in 1160 blocks.
==10516== malloc/free: 177326 allocs, 176166 frees, 505192128 bytes allocated.
==10516== For counts of detected errors, rerun with: -v
==10516== searching for pointers to 1160 not-freed blocks.
==10516== checked 5955140 bytes.
==10516==
==10516==
==10516== 1029 bytes in 2 blocks are definitely lost in loss record 1 of 5
==10516==    at 0x1B904A90: malloc (vg_replace_malloc.c:131)
==10516==    by 0x804B568: gp_alloc (alloc.c:268)
==10516==    by 0x80BB3D8: X11_args (x11.trm:291)
==10516==    by 0x8090785: main (plot.c:380)

This one is happening at line 291 of x11.trm.  This command:

    xargv = (char **) gp_alloc(argc * sizeof(char *), "<xargv>");

uses xargv like a normal pointer (i.e., ++) and never attempts to free the memory within X11_args().  The patch makes xargv a local static variable and duplicates the pointer as p_xargv used as ++p_xargv, etc.

==10516==
==10516==
==10516== 1130 bytes in 76 blocks are definitely lost in loss record 2 of 5
==10516==    at 0x1B904A90: malloc (vg_replace_malloc.c:131)
==10516==    by 0x283AEF: strdup (in /lib/tls/libc-2.3.3.so)
==10516==    by 0x805F403: push (eval.c:484)
==10516==    by 0x805F5BB: execute_at (eval.c:587)

This is right before the bad line in question.

    /* WARNING - This is a memory leak if the string is not later freed */

I'll write off line on this one.

Dan