Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="US-ASCII"
MIME-Version: 1.0
Date: Wed, 22 Aug 2018 20:08:54 +0000
From: "Robert Elz" <kre@netbsd.org>
Subject: CVS commit: src/bin/sh
To: source-changes@NetBSD.org
Message-Id: <20180822200854.66AF8FBEC@cvs.NetBSD.org>
Sender: source-changes-owner@NetBSD.org
Precedence: bulk
Reply-To: source-changes-d@NetBSD.org
Mail-Reply-To: "Robert Elz" <kre@netbsd.org>
Mail-Followup-To: source-changes-d@NetBSD.org

Module Name:	src
Committed By:	kre
Date:		Wed Aug 22 20:08:54 UTC 2018

Modified Files:
	src/bin/sh: eval.c main.c memalloc.c memalloc.h

Log Message:
Fix (hopefully) the problem reported on current-users by Patrick Welche.
we had incorrect usage of setstackmark()/popstackmark()

There was an ancient idiom (imported from CSRG in 1993) where code
can do:
	setstackmark(&smark); loop until whatever condition {
		/* do lots of code */ popstackmark(&smark);
	} popstackmark(&smark);

The 1st (inner) popstackmark() resets the stack, conserving memory,
The 2nd one is needed just in case the "whatever condition" was never
true, and the first one was never executed.

This is (was) safe as all popstackmark() did was reset the stack.
That could be done over and over again with no harm.

That is, until 2000 when a fix from FreeBSD for another problem was
imported.  That connected all the stack marks as a list (so they can be
located).  That caused the problem, as the idiom was not changed, now
there is this list of marks, and popstackmark() was removing an entry.

It rarely (never?) caused any problems as the idiom was rarely used
(the shell used to do loops like above, mostly, without the inner
popstackmark()).  Further, the stack mark list is only ever used when
a memory block is realloc'd.

That is, until last weekend - with the recent set of changes.

Part of that copied code from FreeBSD introduced the idiom above
into more functions - functions used much more, and with a greater
possibility of stack marks being set on blocks that are realloc'd
and so cause the problem.   In the FreeBSD code, they changed the idiom,
and always do a setstackmark() immediately after the inner popstackmark().
But not for reasons related to a list of stack marks, as in the
intervening period, FreeBSD deleted that, but for another reason.

We do not have their issue, and I did not believe that their
updated idiom was needed (I did some analysis of exactly this issue -
just missed the important part!), and just continued using the old one.
Hence Patrick's core dump....

The solution used here is to split popstackmark() into 2 halves,
popstackmark() continues to do what it has (recently) done,
but is now implemented as a call of (a new func) rststackmark()
which does all the original work of popstackmark - but not removing
the entry from the stack mark list (which remains in popstackmark()).
Then in the idiom above, the inner popstackmark() turns into a call of
rststackmark() so the stack is reset, but the stack mark list is
unchanged.  Tail recursion elimination makes this essentially free.


To generate a diff of this commit:
cvs rdiff -u -r1.159 -r1.160 src/bin/sh/eval.c
cvs rdiff -u -r1.75 -r1.76 src/bin/sh/main.c
cvs rdiff -u -r1.31 -r1.32 src/bin/sh/memalloc.c
cvs rdiff -u -r1.17 -r1.18 src/bin/sh/memalloc.h

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.