Re: valgrind

[Ethan A M. <merritt@u.washington.edu>]

On Tuesday 21 March 2006 06:32 pm, James R. Van Zandt wrote:
> Thanks for reminding us about valgrind.
> This leakage turned up every time:
> 
>   ==17498== 156 (36 direct, 120 indirect) bytes in 1 blocks are
>   definitely lost in loss record 5 of 9
>   ==17498==    at 0x1B90459D: malloc (vg_replace_malloc.c:130)
>   ==17498==    by 0x1BC6C179: (within /lib/tls/libc-2.3.5.so)
>   ==17498==    by 0x1BC6C7C1: __nss_database_lookup (in /lib/tls/libc-2.3.5.so)
>   ==17498==    by 0x1B90F139: ???
>   ==17498==    by 0x1B9108F4: ???
>   ==17498==    by 0x1BC1A0B9: getpwnam_r (in /lib/tls/libc-2.3.5.so)
>   ==17498==    by 0x1BC19B41: getpwnam (in /lib/tls/libc-2.3.5.so)
>   ==17498==    by 0x80FA84A: getusername (util.c:1143)
>   ==17498==    by 0x80DD313: PS_common_init (post.trm:2278)
>   ==17498==    by 0x80DD841: PS_init (post.trm:2403)
>   ==17498==    by 0x80B62B9: term_init (term.c:531)
>   ==17498==    by 0x806E993: do_plot (graphics.c:1301)

I am not seeing that error here, or at least not for
"setenv GNUTERM post; \
 valgrind --leak-check=full --log-file=valgrind gnuplot all.dem </bin/true >foo"

> show that this allocation in post.trm leaks memory:
> 
> 	    ps_fontfile_char = gp_alloc (totlength+1,"ps_fontfile_char");

I already knew about this leak, but have not found the proper place to 
free the pointers.  They are copied to an array which is used in several
places.  IIRC this is Harald Harders' code. Perhaps he can help.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742