From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-38173-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 6778 invoked by alias); 17 Mar 2016 18:34:19 -0000
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-Seq: 38173
Received: (qmail 12925 invoked from network); 17 Mar 2016 18:34:17 -0000
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-f79b16d000005389-63-56eaf64a0bb5
Date: Thu, 17 Mar 2016 18:24:06 +0000
From: Peter Stephenson <p.stephenson@samsung.com>
To: zsh-workers@zsh.org
Subject: Re: segfault in completion for configure
Message-id: <20160317182406.2cb566ed@pwslap01u.europe.root.pri>
In-reply-to: <160317111515.ZM16697@torch.brasslantern.com>
References: <20160311134729.GA32476@cventin.lip.ens-lyon.fr>
 <20160311143202.4008e29b@pwslap01u.europe.root.pri>
 <160311150056.ZM30997@torch.brasslantern.com>
 <20160312031116.GC28459@zira.vinc17.org>
 <160312082029.ZM2340@torch.brasslantern.com>
 <160312093420.ZM14020@torch.brasslantern.com>
 <20160313215831.GA23404@zira.vinc17.org>
 <160314194323.ZM6887@torch.brasslantern.com>
 <20160317152435.GC11303@cventin.lip.ens-lyon.fr>
 <160317111515.ZM16697@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+NgFrrELMWRmVeSWpSXmKPExsVy+t/xy7pe316FGbRuFbQ42PyQyYHRY9XB
	D0wBjFFcNimpOZllqUX6dglcGZcOfmAsWMlW0b1oL2MDYzNrFyMnh4SAiUT/zrPMELaYxIV7
	69m6GLk4hASWMkr0b3vHDOHMYJK4fPcwK4RzjlHi5I63UGVnGSW65rcygvSzCKhKnDx3Hmwu
	m4ChxNRNs8HiIgLiEmfXnmcBsYWB4g9/zwPbxytgL7H62S+wOKeAlcTEFUehhr5klth79gVY
	gl9AX+Lq309MEAfaS8y8coYRollQ4sfke2A1zAJaEpu3NbFC2PISm9e8BVsgJKAucePubvYJ
	jMKzkLTMQtIyC0nLAkbmVYyiqaXJBcVJ6blGesWJucWleel6yfm5mxghIf11B+PSY1aHGAU4
	GJV4eBnOvQwTYk0sK67MPcQowcGsJMIr/+lVmBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHembve
	hwgJpCeWpGanphakFsFkmTg4pRoYq65VqPkun7DDSCFx+rYTv8UkS2Yadlhc+7a+L2rngtSl
	9QZXRbWU79ezTMjx5ZHoVGTb0mBT+f9amGN6sOxjkbf/7xsXC21smOr1SIkzL7Bj+RHlYxEF
	tR92ejTMusF5MS93bdLHFese/jA2v754IpN7blL2KoFAWfZTt/e8eTjv6DeBy8L2SizFGYmG
	WsxFxYkA3v8Qe2UCAAA=

On Thu, 17 Mar 2016 11:15:15 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> Yeah, nothing really new here, this is exactly what I would expect
> to see:  The hander returns and thereafter pattern matching is messed
> up and crashes when it tries to pick up where it left off.

We could add a variable that triggers an abort when the signal handler
runs in pattern matching, but does that tell us anything beyond, er, it
was running in pattern matching?  If not, what sort of information could
we get from this?  Dump some state when we return from the signal
handler and detect we've been in it?  Or is that if we know we've been
int he signal handler at that point we already know the place where we
needed to queue signals...

I don't think I've actually suggested anything.

pws