Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: signal mask bug?
- X-seq: zsh-workers 40549
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: Re: signal mask bug?
- Date: Wed, 15 Feb 2017 20:10:44 -0800
- Authentication-results: amavisd4.gkg.net (amavisd-new); dkim=pass (2048-bit key) header.d=brasslantern-com.20150623.gappssmtp.com
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=ofFbLrWJkW3WV3UGgcrTB+6iUpjlPvNJbYlSDOcllU4=; b=Al81zOF+VQpEytkZmv/H4vaeBWpKg0Doez2RIY/7S6+xvRQcinetqSENwTtneTh2jz zBd81hjnIn/CQGTqx101odgpyR0EKrol+C8PtqV8B66q+Lpx+Ad9At1wXhoIhm6A/LrF aBc/BFiM0SRAAhw0fL0j9W3TrnVsb3hWwEhJDFEK8xRJJ1739AvJYxFsnHBDkh5MuVlo Rdf28mrD5Fx09lHTw8IBizYfkJJ++fmWQY4aGr2WwO3bphE6+A/zYyBshUPblVdmAO2i 1e6RxXmFNnfGydm70Cw/3tc4j1p6MP7Fo427kVY9r6IklW+30kF4e78JzuQYhyr/dtlB kkSg==
- In-reply-to: <20170215221757.GA24355@lorien.comfychair.org>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <20170215221757.GA24355@lorien.comfychair.org>
On Feb 15, 2:17pm, Danek Duvall wrote:
}
} % jobs
} [1] + running sleep 30 |
} unknown signal (core dumped) cat
}
} Of course, nothing actually dumped core, suggesting it's just a reporting
} problem.
Hm. This indicates that WCOREDUMP() is returning true for whatever the
job status of the cat process is.
However, presumably the status of that job should have been set to
SP_RUNNING at the same time it was for "sleep".
Which it is -- makerunning() assigns SP_RUNNING to pn->status of "cat"
during "bg".
But then when we reach prinjob() from the "jobs" command, pn->status of
that job has changed from -1 to 65535.
This happens at signals.c:525 in wait_for_processes(), when the status
returned from wait3(&status) [line 457] is assigned to it.
I suspect the status returned from wait3 is invalid in this case, but
I'm not sure. What would a status of 65535 mean? Or should it be
masked in some way that it isn't?
Messages sorted by:
Reverse Date,
Date,
Thread,
Author