Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
RE: Final (?) info on signals/crashes when suspending "mutt" function
- X-seq: zsh-workers 6888
- From: "Andrej Borsenkow" <Andrej.Borsenkow@xxxxxxxxxxxxxx>
- To: "Sven Wischnowsky" <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>, <zsh-workers@xxxxxxxxxxxxxx>
- Subject: RE: Final (?) info on signals/crashes when suspending "mutt" function
- Date: Mon, 28 Jun 1999 12:14:14 +0400
- Importance: Normal
- In-reply-to: <199906280704.JAA09417@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
> I also build a patch over the weekend that tried to address Andrej's
> problems, it's appended below.
It does not help (sigh). Unfortunately, I'm beginning to suspect OS bug. The
visible problem is, that Zsh does not get SIGCHLD when child stops. Unless Zsh
somehow blocks SIGCHLD (but I fail to see why it does it when started as first
level shell but does not otherwise) this looks like SIGCHLD not being sent in
this case. Again, I suspect, why it can happen:
man 2 signal
If signal() or sigset() is used to set SIGCHLD's disposition to a sig-
nal handler, SIGCHLD will not be sent when the calling process' chil-
dren are stopped or continued.
At least xterm (and probably dtterm and getty/login) are using signal() to play
with SIGCHLD before exec'ing shell. So, I can imagine some non-trivial bug, that
subsequent sigaction() won't reset SA_NOCLDSTOP. Unfortunately, I could not
reproduce it in obvious way.
/andrej
Messages sorted by:
Reverse Date,
Date,
Thread,
Author