Re: [bug-gawk] $0 reassignment corruption in 4.2

[arnold]

Andy,

Try swapping the order of the statements in reset_record(). Just
a guess.

Thanks,

Arnold

"Andrew J. Schorr" <address@hidden> wrote:

> On Mon, Nov 13, 2017 at 03:04:27PM -0800, Eric Pruitt wrote:
> > On Mon, Nov 13, 2017 at 05:58:18PM -0500, Andrew J. Schorr wrote:
> > > There's good news and bad news. I think the attached patch fixes the
> > > assertion failure. But I don't think it fixes the corruption that Eric
> > > found.
> > >
> > > Eric -- can you please test?
> > 
> > You are correct. The data still gets corrupted when I run mdlint with a
> > patched GAWK 4.2.0.
>
> I think the attached test case demonstrates the bug. I don't have a fix
> yet. The output should be "nim", but it's garbage in 4.2 (3 NUL characters).
>
> Valgrind pukes on this:
>
> ==342== Invalid read of size 2
> ==342==    at 0x4C2E0D0: memcpy@@GLIBC_2.14 (vg_replace_strmem.c:1018)
> ==342==    by 0x449E05: purge_record (field.c:353)
> ==342==    by 0x441D3B: r_interpret (interpret.h:706)
> ==342==    by 0x40DA59: main (main.c:505)
> ==342==  Address 0x6068cf0 is 0 bytes inside a block of size 4 free'd
> ==342==    at 0x4C2ACDD: free (vg_replace_malloc.c:530)
> ==342==    by 0x45F418: r_unref (node.c:480)
> ==342==    by 0x4436B9: unref (awk.h:1887)
> ==342==    by 0x4436B9: r_interpret (interpret.h:702)
> ==342==    by 0x40DA59: main (main.c:505)
> ==342==  Block was alloc'd at
> ==342==    at 0x4C29BE3: malloc (vg_replace_malloc.c:299)
> ==342==    by 0x460074: emalloc_real (awk.h:1950)
> ==342==    by 0x460074: make_str_node (node.c:386)
> ==342==    by 0x424210: do_substr (builtin.c:1869)
> ==342==    by 0x4403D5: r_interpret (interpret.h:962)
> ==342==    by 0x40DA59: main (main.c:505)
> ==342== 
> ==342== Invalid read of size 1
> ==342==    at 0x4C2E240: memcpy@@GLIBC_2.14 (vg_replace_strmem.c:1018)
> ==342==    by 0x449E05: purge_record (field.c:353)
> ==342==    by 0x441D3B: r_interpret (interpret.h:706)
> ==342==    by 0x40DA59: main (main.c:505)
> ==342==  Address 0x6068cf2 is 2 bytes inside a block of size 4 free'd
> ==342==    at 0x4C2ACDD: free (vg_replace_malloc.c:530)
> ==342==    by 0x45F418: r_unref (node.c:480)
> ==342==    by 0x4436B9: unref (awk.h:1887)
> ==342==    by 0x4436B9: r_interpret (interpret.h:702)
> ==342==    by 0x40DA59: main (main.c:505)
> ==342==  Block was alloc'd at
> ==342==    at 0x4C29BE3: malloc (vg_replace_malloc.c:299)
> ==342==    by 0x460074: emalloc_real (awk.h:1950)
> ==342==    by 0x460074: make_str_node (node.c:386)
> ==342==    by 0x424210: do_substr (builtin.c:1869)
> ==342==    by 0x4403D5: r_interpret (interpret.h:962)
> ==342==    by 0x40DA59: main (main.c:505)
> ==342== 
> nim
>
> Without my previous patch, the assertion fails. But even with my patch,
> it's not copying the field data soon enough. It seems that the new $0 value
> is getting set prior to purge_record, so the $1 has already been stomped on.
>
> Regards,
> Andy