#77 memory leaks in score

[Anonymous]

valgrind shows memory leaks, please see attached
testcases (as requested!)

Ed

ed.spittles at artofsilicon.com

[Nobody/Anonymous]

three small synthetic testcases with valgrind logs

[Trevor Williams]

Logged In: YES
user_id=512771

Thanks! I will get crackin' on these ASAP.

[Trevor Williams]

Logged In: YES
user_id=512771

I have attached a tarball that fixes these memory leak
problems. Please copy it to your covered-0.4.5/src
directory an unzip/untar it there. Note that the files
contained in this tarball do not overlap with the tarball
for bug 1519527.

[Trevor Williams]

Files to fix memory leak issues found with the x.tgz cases

[Nobody/Anonymous]

Logged In: NO

Thanks for the updates. Applying both the tarballs, I still
see memory leaks with valgrind. (There is also a memory
leak with the case previously segfaulting.)

I can try to look deeper into that later today - I'd
appreciate any pointers as to what I can do. We should be
seeing the same results!

Sourceforge seems to allow me only one upload per bug
(perhaps because I still lack a login) - can I email you
with an attachment?

Cheers
Ed

[Nobody/Anonymous]

Logged In: NO

Hi
I added some debug instrumentation to your code, and
post-processed the results with a bit of awk, and can see a
bit more detail as to which allocations are never freed, for
example:

egrep bf7c8 covered-tc-1-leak/valgrind.D.log
In malloc_safe, addr: 0x46bf7c8, file: expr.c, line
347
In expression_create, id: 4, op: SUBTRACT, line: 29,
addr: 0x46bf7c8

as opposed to:
egrep c0ef0 covered-tc-1-leak/valgrind.D.log
In malloc_safe, addr: 0x46c0ef0, file: expr.c, line 347
In expression_create, id: 13, op: NASSIGN, line: 41,
addr: 0x46c0ef0
In free_safe, addr: 0x46c0ef0

As you see, I instrumented your free_safe and malloc_safe
and chose also to instrument expression_create (because
valgrind indicated it was leaking)

I wasn't able to drive valgrind/gdb well enough to get there
without code changes.

The awk was the usual quick and dirty stuff:
awk '/alloc_safe/{a[$4]=$0}/free_safe/{delete
a[$4","]}END{for (i in a) print a[i]}'
covered-tc-1-leak/valgrind.D.log
In malloc_safe, addr: 0x46bfce0, file: ./parser.y,
line 3422
In malloc_safe, addr: 0x46becc0, file: vector.c, line 118
In malloc_safe, addr: 0x46bf7c8, file: expr.c, line 347
In malloc_safe, addr: 0x46bf4f8, file: expr.c, line 363
In malloc_safe, addr: 0x46c20e8, file: expr.c, line 316
In malloc_safe, addr: 0x46bf870, file: expr.c, line 363
In malloc_safe, addr: 0x46bf690, file: expr.c, line 347
In malloc_safe, addr: 0x46bf4c0, file: expr.c, line 359
In malloc_safe, addr: 0x46bed10, file: expr.c, line 347
In malloc_safe, addr: 0x46bf738, file: expr.c, line 363
In malloc_safe, addr: 0x46bf9f8, file: ./parser.y,
line 3422
In malloc_safe, addr: 0x46bf838, file: expr.c, line 359
In malloc_safe, addr: 0x46bf700, file: expr.c, line 359
In malloc_safe, addr: 0x46bf778, file: static.c, line 233
In malloc_safe, addr: 0x46bf450, file: expr.c, line 347
In malloc_safe, addr: 0x46bec80, file: vector.c, line 115
In malloc_safe, addr: 0x46bed80, file: expr.c, line 359

Cheers
Ed

[Nobody/Anonymous]

Logged In: NO

Hi
I tried a build from your CVS: it does indeed come out
much cleaner (not sure why the tarballs didn't work for me)
Typical output is
==14061== 43 bytes in 4 blocks are definitely lost in loss
record 3 of 3
==14061== at 0x46214D1: malloc (vg_replace_malloc.c:149)
==14061== by 0x46B318F: strdup (in /lib/tls/libc-2.3.2.so)
==14061== by 0x807F72E: score_add_arg (score.c:342)
==14061== by 0x807F9DC: score_parse_args (score.c:533)
==14061== by 0x80805BE: command_score (score.c:682)
==14061== by 0x8078114: main (main.c:145)

Cheers
Ed

[Trevor Williams]

Logged In: YES
user_id=512771

I have fixed this latest memory leak problem and checked it
into CVS. If you would like to use the latest stable branch
of CVS, use the -r covered-0_4_5-branch release name (i.e.,
'cvs update -r covered-0_4_5-branch'. Otherwise, you will
be attempting to use what will be the next development
release of Covered (which may be a bit buggy going forward
as I am working on adding support for generate blocks at the
moment).

[Trevor Williams]

Logged In: YES
user_id=512771

This bug has been fixed and will be available in the 0.4.6
stable release.