Re: gawk: other double free(_wstr)

[Andrew J. Schorr]

On Fri, Jan 12, 2007 at 01:52:28PM +0100, Karel Zak wrote:
> On Fri, Jan 12, 2007 at 02:29:34PM +0200, Aharon Robbins wrote:
> > I don't get this with my current sources, which should be appearing
> > on the Savannah CVS archive within an hour or two.  Valgrind is happy.
> 
...
> 
>  $ echo -e "AAA BBX\nAAA BBY" | ./gawk ' /^AAA BB/ { x = substr($2,
>  1); $1 = "FOO"; print $0 }'
> 

I think there may be a silly confusion here.  If you run csh,
then the command 'echo -e "AAA BBX\nAAA BBY"' gives this:

   csh: echo -e "AAA BBX\nAAA BBY" 
   -e AAA BBX
   AAA BBY

whereas with bash, one gets this:

   bash-3.00$ echo -e "AAA BBX\nAAA BBY"
   AAA BBX
   AAA BBY

So, for a user running csh or a variant, the test code gives entirely
different results.

On my system using bash to run the test, I see:

bash-3.00$  echo -e "AAA BBX\nAAA BBY" | ./gawk ' /^AAA BB/ { x = substr($2, 
1); $1 = "FOO"; print $0 }'
FOO BBX
*** glibc detected *** gawk: double free or corruption (fasttop): 
0x000000000055d880 ***
...

And with valgrind:

bash-3.00$  echo -e "AAA BBX\nAAA BBY" | valgrind ./gawk ' /^AAA BB/ { x = 
substr($2, 1); $1 = "FOO"; print $0 }'
==29343== Memcheck, a memory error detector.
==29343== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==29343== Using LibVEX rev 1471, a library for dynamic binary translation.
==29343== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==29343== Using valgrind-3.1.0, a dynamic binary instrumentation framework.
==29343== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==29343== For more details, rerun with: -v
==29343== 
FOO BBX
==29343== Invalid free() / delete / delete[]
==29343==    at 0x4A1E573: free (vg_replace_malloc.c:235)
==29343==    by 0x429307: free_wstr (node.c:770)
==29343==    by 0x429890: unref (node.c:516)
==29343==    by 0x41F894: reset_record (field.c:294)
==29343==    by 0x41F8D0: set_record (field.c:244)
==29343==    by 0x424904: inrec (io.c:355)
==29343==    by 0x42496C: do_input (io.c:463)
==29343==    by 0x428A22: main (main.c:607)
==29343==  Address 0x4FEC9F8 is 0 bytes inside a block of size 20 free'd
==29343==    at 0x4A1E573: free (vg_replace_malloc.c:235)
==29343==    by 0x429307: free_wstr (node.c:770)
==29343==    by 0x429890: unref (node.c:516)
==29343==    by 0x4206D5: get_field (field.c:213)
==29343==    by 0x4132C8: do_print_rec (builtin.c:1717)
==29343==    by 0x43C491: interpret (eval.c:792)
==29343==    by 0x43C3BF: interpret (eval.c:477)
==29343==    by 0x43C215: interpret (eval.c:456)
==29343==    by 0x424959: do_input (io.c:461)
==29343==    by 0x428A22: main (main.c:607)
FOO BBY
==29343== 
==29343== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 1)
==29343== malloc/free: in use at exit: 24,588 bytes in 105 blocks.
==29343== malloc/free: 328 allocs, 224 frees, 38,779 bytes allocated.
==29343== For counts of detected errors, rerun with: -v
==29343== searching for pointers to 105 not-freed blocks.
==29343== checked 125,592 bytes.
==29343== 
==29343== LEAK SUMMARY:
==29343==    definitely lost: 0 bytes in 0 blocks.
==29343==      possibly lost: 0 bytes in 0 blocks.
==29343==    still reachable: 24,588 bytes in 105 blocks.
==29343==         suppressed: 0 bytes in 0 blocks.
==29343== Reachable blocks (those to which a pointer was found) are not shown.
==29343== To see them, rerun with: --show-reachable=yes

So I think the bug is a real one.

I think the fix may be simply to turn off the WSTRCUR flag,
as Karel suggested:

--- field.c     10 Jan 2006 20:04:21 -0000      1.3
+++ field.c     12 Jan 2007 14:01:01 -0000
@@ -206,7 +197,7 @@ rebuild_record()
                                }
                        } else {
                                *n = *(fields_arr[i]);
-                               n->flags &= ~(MALLOC|TEMP|PERM|STRING);
+                               n->flags &= ~(MALLOC|TEMP|PERM|STRING|WSTRCUR);
                        }
 
                        n->stptr = cops;

I'm not sure whether any other flags should also be turned off.
I'm sure Arnold will have a much more intuitive sense of this...

Regards,
Andy