Re: [bug-gawk] Memory leak

[Andrew J. Schorr]

Hi,

> ==19925== 11,301,792 bytes in 117,727 blocks are still reachable in loss 
> record 124 of 124
> ==19925==    at 0x4A0717A: malloc (vg_replace_malloc.c:298)
> ==19925==    by 0x480FDE: emalloc_real (awk.h:1820)
> ==19925==    by 0x482599: bcalloc (symbol.c:722)
> ==19925==    by 0x40BBDA: assoc_list (array.c:1329)
> ==19925==    by 0x4477C9: r_interpret (interpret.h:900)
> ==19925==    by 0x4605F8: main (main.c:518)

This is what worries me. It does seem to correspond to a leak related to using
a user-defined sorting function. Looking at the code, I don't see why it's not
getting freed, unless this test is bailing out early before we free the
allocated instruction below:

        if (list == NULL || ! cmp_func || (assoc_kind & (AASC|ADESC)) != 0)
                        return list;    /* empty list or unsorted, or list 
already sorted */

We know that cmp_func is not NULL, but perhaps list is NULL or
the assoc_kind flags were modified by symbol->alist. If this test fails,
then we return before we pop the instruction and free it, so it's still
on the stack and reachable...

Does the attached, not well-tested, patch fix your memory leak?

Regards,
Andy

assoc_list.patch
Description: Text document