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

[arnold]

Andy's patch is necessary but not sufficient. (You knew that.)

I did some work. It's happening at Op_store_field in interpret.h.
The UNFIELD macro is not smart enough. (Surprise, suprise.)  I wasn't
able to fix it without breaking the test suite. But that's the area
to look at; we need to be smarter if we're assigning to field 0, but
I don't know yet what to do.

I'm not sure if we need to muck about inside UNFIELD or just in the
code for that case.

Andy - feel free to take it from there.

Arnold

address@hidden wrote:

> 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