Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.1
X-AuditID: cbfec7f5-f792a6d000001302-17-56efd0382aea
Date: Mon, 21 Mar 2016 10:43:01 +0000
From: Peter Stephenson <p.stephenson@samsung.com>
To: zsh-workers@zsh.org
Subject: Re: access already freed memory when resize window
Message-id: <20160321104301.0ff32aae@pwslap01u.europe.root.pri>
In-reply-to: <160320101910.ZM8306@torch.brasslantern.com>
References:
 <CAKzW8okOFzO=ZNdi4HkKuQDnDdqAkQELmXGYJ3XSoho_kvJNzw@mail.gmail.com>
 <160320101910.ZM8306@torch.brasslantern.com>
Organization: Samsung Cambridge Solution Centre
X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu)
MIME-version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
X-Brightmail-Tracker:
 H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsVy+t/xK7oWF96HGTzsM7Y42PyQyYHRY9XB
	D0wBjFFcNimpOZllqUX6dglcGYuPHWArOMNc8XlFE1MD4xemLkZODgkBE4mN265C2WISF+6t
	Z+ti5OIQEljKKHHm6zwWCGcGk8SRz42sIFVCAucYJe7MU4dInGWUaF0/nQUkwSKgKtGx4hEj
	iM0mYCgxddNsMFtEQFzi7NrzQDUcHMIC1hJHb3uDhHkF7CU2/F/LDmJzClhK9Ez9ALW5kVFi
	6at5YMv4BfQlrv79BHWevcTMK2cYIZoFJX5Mvge2l1lAS2LztiZWCFteYvOat8wQh6pL3Li7
	m30Co/AsJC2zkLTMQtKygJF5FaNoamlyQXFSeq6RXnFibnFpXrpecn7uJkZIOH/dwbj0mNUh
	RgEORiUeXoZV78OEWBPLiitzDzFKcDArifDWnQEK8aYkVlalFuXHF5XmpBYfYpTmYFES5525
	632IkEB6YklqdmpqQWoRTJaJg1OqgVHz8Qu11Rlh11p6Jnzzdk8o3NfBX/T1fdoX/wsLxI+I
	/lqsManSK2T+Rf3CvxkPbj2rNTHxPiPkMvGFvQ7rTzeT3PY7f30XFDWY1XKHGa77rCm3tNnD
	KUStJKbwyIc/BovTr64Wm/JXP3wCR3XlBt+OSUxyB6cL/j55SaWs0/Lv0vb+2RV2d5VYijMS
	DbWYi4oTAd9STU9jAgAA
X-Seq: zsh-workers 38194

On Sun, 20 Mar 2016 10:19:10 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> It doesn't even help to queue signals, because waiting for the command
> substitution to finish must temporarily unqueue them.

Right, but shouldn't there at least be some attempt to tame the points
at which recursion can happen?  Or is that already happening, and all
the effects we're seeing are out at the top level after the signal
handler has returned?

pws