Re: [bug-gawk] memory leak/corruption issues

[Andrew J. Schorr]

Actually, the attached patch may be slightly more useful in chasing down
lost nodes.

To take one memory corruption example:

bash-4.2$ valgrind ./gawk -f test/nsprof2.awk --pretty-print=/tmp/out
==19824== Memcheck, a memory error detector
==19824== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==19824== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==19824== Command: ./gawk -f test/nsprof2.awk --pretty-print=/tmp/out
==19824== 
==19824== Invalid read of size 4
==19824==    at 0x45D674: pp_concat (profile.c:1897)
==19824==    by 0x45D674: pprint (profile.c:555)
==19824==    by 0x45ED35: pp_func (profile.c:1999)
==19824==    by 0x461FB6: foreach_func (symbol.c:491)
==19824==    by 0x40F06C: dump_funcs (awkgram.y:4936)
==19824==    by 0x407F11: main (main.c:527)
==19824==  Address 0x62952e8 is 104 bytes inside a block of size 112 free'd
==19824==    at 0x4C2ACBD: free (vg_replace_malloc.c:530)
==19824==    by 0x45D637: pp_concat (profile.c:1890)
==19824==    by 0x45D637: pprint (profile.c:555)
==19824==    by 0x45ED35: pp_func (profile.c:1999)
==19824==    by 0x461FB6: foreach_func (symbol.c:491)
==19824==    by 0x40F06C: dump_funcs (awkgram.y:4936)
==19824==    by 0x407F11: main (main.c:527)
==19824==  Block was alloc'd at
==19824==    at 0x4C29BC3: malloc (vg_replace_malloc.c:299)
==19824==    by 0x45A602: emalloc_real (awk.h:1989)
==19824==    by 0x45A602: r_getblock (node.c:1043)
==19824==    by 0x45A79A: pp_push (profile.c:178)
==19824==    by 0x45DDB4: pprint (profile.c:365)
==19824==    by 0x45ED35: pp_func (profile.c:1999)
==19824==    by 0x461FB6: foreach_func (symbol.c:491)
==19824==    by 0x40F06C: dump_funcs (awkgram.y:4936)
==19824==    by 0x407F11: main (main.c:527)
==19824== 
==19824== 
==19824== HEAP SUMMARY:
==19824==     in use at exit: 113,287 bytes in 1,372 blocks
==19824==   total heap usage: 1,902 allocs, 530 frees, 167,224 bytes allocated
==19824== 
==19824== LEAK SUMMARY:
==19824==    definitely lost: 0 bytes in 0 blocks
==19824==    indirectly lost: 0 bytes in 0 blocks
==19824==      possibly lost: 0 bytes in 0 blocks
==19824==    still reachable: 113,287 bytes in 1,372 blocks
==19824==         suppressed: 0 bytes in 0 blocks
==19824== Rerun with --leak-check=full to see details of leaked memory
==19824== 
==19824== For counts of detected and suppressed errors, rerun with: -v
==19824== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

I'm not sure what's going on. At first, I thought the problem was
that pp_push was failing to set n->valref = 1. But it seems that the code
in profile.c does not use the normal reference counting approach...

The attached patch seems to fix this bug, but it's pretty mindless. It also
fixes some of the other valgrind complaints, but not all of them.

Regards,
Andy

memdebug.patch
Description: Text document

profile.patch
Description: Text document