Re: storage_sink_open is leaky

[John Darrington]

On Sun, Jan 23, 2005 at 11:06:18PM -0800, Ben Pfaff wrote:

     Okay, I updated to the latest CVS and with
             make check SUPERVISOR='valgrind --leak-check=yes'
     I only see one leak:
             ==3402== 36 bytes in 1 blocks are definitely lost in loss record 2 
of 4
             ==3402==    at 0x1B904EDD: malloc (vg_replace_malloc.c:131)
             ==3402==    by 0x8073DC6: xmalloc (alloc.c:39)
             ==3402==    by 0x80888FB: dfm_open_writer (dfm-write.c:52)
             ==3402==    by 0x80B3C98: internal_cmd_print (print.c:190)
             ==3402==    by 0x80B3AD1: cmd_print (print.c:114)
             ==3402==    by 0x807A706: cmd_parse (command.c:207)
             ==3402==    by 0x80A2ECB: execute_command (main.c:134)
             ==3402==    by 0x80A2E7C: parse_script (main.c:104)
             ==3402==    by 0x80A2E18: main (main.c:91)
     This one is simple, so I have checked in a fix.
     

Thanks.


     Are you using --show-reachable=yes on the valgrind command line?
     Those are not really leaks, because that data is still reachable
     at program exit, and so I don't think they are really worth
     "fixing".


I see your point, but I can't totally agree.  There may be cases where
our test examples  result in the memory being "still reachable", but a
more complex example it would be "definitely lost". 
For example, if a particular command forgets to clean up, then a test
script which calls that command just once, will give a "still
reachable", but if that command was called many times in a complex
script, it'd be a definite leak.

     
     By the way, every test I run reports this error:
             ==3122== Invalid free() / delete / delete[]
             ==3122==    at 0x1B905460: free (vg_replace_malloc.c:153)
             ==3122==    by 0x80696DB: done_settings (set.q:1059)
             ==3122==    by 0x809B609: done_glob (glob.c:190)
             ==3122==    by 0x808B540: err_hcf (error.c:231)
             ==3122==    by 0x80A2EF9: execute_command (main.c:129)
             ==3122==    by 0x80A2E7C: parse_script (main.c:104)
             ==3122==    by 0x80A2E18: main (main.c:91)
             ==3122==  Address 0x52BFEDD4 is on thread 1's stack
     I think this must be something you introduced in the latest
     check-in.



Hmm.  I can't produce this problem.  Did you compile/configure with any
non-default  options ??


John

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://wwwkeys.pgp.net or any PGP keyserver for public key.

pgpE1KHDXCyKU.pgp
Description: PGP signature