[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Andrew J. Schorr
Subject: Re: [bug-gawk] $0 reassignment corruption in 4.2
Date: Tue, 14 Nov 2017 08:53:14 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

On Tue, Nov 14, 2017 at 04:14:30AM -0700, address@hidden wrote:
> 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.

The problem occurs when we unref the current $0 two lines before UNFIELD, as is
seen in the valgrind output. At that moment, the $1 value is still pointing
into the $0 buffer, so freeing $0 is not OK.

> Andy - feel free to take it from there.

I think we may just need to add a special check in Op_store_field for
assignments to $0, but I'm not certain of that. Maybe the call to the assign
function pointer simply needs to come before the unref call, or something like

In fact, making that change solves this test case. And it passes "make check"
and "make valgrind-noleak". And I think it fixes Eric's initial bug report.

Combined patch attached. Eric -- can you please confirm this fixes your issue?

Arnold -- does this look right to you? I haven't chased down all the nuances
of what this assign function is doing...


Attachment: field0.patch
Description: Text document

reply via email to

[Prev in Thread] Current Thread [Next in Thread]