Re: 3.0.6-pre-5 problem

Re: 3.0.6-pre-5 problem

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Jun 25, 11:38am, Sven Wischnowsky wrote:
> } Subject: Re: 3.0.6-pre-5 problem
> }
> } I hope this fixes it.
> 
> No such luck.  Here's "pstree" output:
> 
> zsh(28198)-+-pstree(4199)
>            |-xterm(4146)---zsh(4147)-+-mutt(4149)
>            |                         `-zsh(4153)
>            `-xterm(4191)---zsh(4192)---zsh(4194)---mutt(4196)
> 
> The first xterm (4146) I ran the "mutt" function directly from the top
> shell and then hit ^Z.  4149 and 4153 are both stopped; 4146 is blocked
> in wait4() which means that 4147 can't get any keystrokes (the xterm
> isn't feeding it) which is the hang that Jos sees.
> 
> The second xterm (4191) I ran a new zsh -f (4194) and then the "mutt"
> function; there, 4194 and 4196 are stopped.
> 
> Note that in the first case zsh created an extra dummy job, but in the
> second case it didn't.  This must have something to do with which process
> is the group leader.

(To Bart: I was doing it inside an xterm, but from a bash that ran
inside the xterm.)

I could finally reproduce it when trying to look at it with strace,
which finally opened my eyes (I would have needed a `ps j' output). It 
goes like this: Someone exec()s zsh without putting it into its own
process group. Then we start the function and zsh executes external
commands in its own process group. Then the user hits ^Z and all three 
of them receive the SIGTSTP. The external command is stopped, which is 
fine, zsh ignores it, which is better, and the parent of zsh happens
to not ignore it and stopt, which is deadly.

So, if we have agreed to use the kill-loop-patches, we'll have to make 
sure that every decent interactive zsh with job-control runs in its
own process group which is what the patch below does.

Ok. Since I still couldn't reproduce the exact original problem, I'd
be thankful for any response (*especially* if it's fixed).

Bye
 Sven

P.S.: Peter: 6838 should be superfluous, but I still like the look of 6848.

--- os/init.c	Thu Jun 24 19:00:56 1999
+++ Src/init.c	Fri Jun 25 14:41:12 1999
@@ -390,7 +390,16 @@
 #ifdef JOB_CONTROL
     /* If interactive, make the shell the foreground process */
     if (opts[MONITOR] && interact && (SHTTY != -1)) {
-	attachtty(GETPGRP());
+      /* Since we now sometimes execute programs in the process group
+       * of the parent shell even when using job-control, we have to
+       * make sure that we run in our own process group. Otherwise if
+       * we are called from a program that doesn't put us in our own
+       * group a SIGTSTP that we ignore might stop our parent process.
+       * Instead of the two calls below we once had:
+       *   attachtty(GETPGRP());
+       */
+	attachtty(getpid());
+	setpgrp(0L, 0L);
 	if ((mypgrp = GETPGRP()) > 0) {
 	    while ((ttpgrp = gettygrp()) != -1 && ttpgrp != mypgrp) {
 		sleep(1);

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: 3.0.6-pre-5 problem

[Peter Stephenson]

(I tried to reply to this several times before but it doesn't seem to have
worked, due to the @!$*! disk being full again.)

Sven Wischnowsky wrote:
> So, if we have agreed to use the kill-loop-patches, we'll have to make 
> sure that every decent interactive zsh with job-control runs in its
> own process group which is what the patch below does.

Does this have implications for sending signals from the Ctrl-Button1 menu
of an xterm, not that that ever worked for me anyway?

By the way, although this is totally unrelated, looking at this I
discovered that
  SHELL=/usr/bin/ksh xterm &
creates an xterm with terminal settings messed up.  Without the & it's OK.

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Xterm terminal settings (Re: 3.0.6-pre-5 problem)

[Bart Schaefer]

On Jun 25,  5:56pm, Peter Stephenson wrote:
} Subject: Re: 3.0.6-pre-5 problem
}
} By the way, although this is totally unrelated, looking at this I
} discovered that
}   SHELL=/usr/bin/ksh xterm &
} creates an xterm with terminal settings messed up.  Without the & it's OK.

I believe this to be an OS pty-allocation problem rather than a zsh problem.
I've seen it before in contexts unrelated to zsh.  SunOS in particular is a
culprit; what's happening is that the tty driver for the pseudo-tty copies
its settings from the current controlling terminal of the process that opens
the master side.  When the master process (xterm in this case) doesn't have
an associated tty, the pty gets bad values -- on SunOS, it gets the values
for the system console, which are generally nothing like what you want an
xterm to have.

(It just occurred to me that this problem may show up on any system that
uses STREAMS modules instead of BSD-style TTY drivers.)

Anyway, for several releases of X11 now there's been a resource for setting
your xterm TTY values to work around this bug; it's XTerm*ttyModes: and the
value looks like an stty command line (without the command name).

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: 3.0.6-pre-5 problem

[Bart Schaefer]

On Jun 25,  2:52pm, Sven Wischnowsky wrote:
} Subject: Re: 3.0.6-pre-5 problem
}
} I could finally reproduce it when trying to look at it with strace,
} which finally opened my eyes (I would have needed a `ps j' output).

 PPID   PID  PGID   SID TTY TPGID  STAT  UID   TIME COMMAND
 5161  5162  5162  5162  p4  5162  T     674   0:00 Src/zsh -f 
 5162  5164  5162  5162  p4  5162  T     674   0:00 mutt 
28198  5165  5165 28198  p3  5165  R     674   0:00 ps j 
28198  5161  5161 28198  p3  5169  S       0   0:00 xterm -e Src/zsh -f 

zsh(28198)-+-pstree(5173)
           `-xterm(5161)---zsh(5162)---mutt(5164)

} It goes like this: Someone exec()s zsh without putting it into its own
} process group. Then we start the function and zsh executes external
} commands in its own process group.

The top-level xterm case is now producing process trees exactly like
the case where there's an intermediate zsh, but the parent zsh is still
not ignoring the TSTP.

} So, if we have agreed to use the kill-loop-patches, we'll have to make 
} sure that every decent interactive zsh with job-control runs in its
} own process group which is what the patch below does.

This is a good idea in any case.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: 3.0.6-pre-5 problem

[Bart Schaefer]

On Jun 25,  4:29pm, Bart Schaefer wrote:
} Subject: Re: 3.0.6-pre-5 problem
}
} zsh(28198)-+-pstree(5173)
}            `-xterm(5161)---zsh(5162)---mutt(5164)
} 
} The top-level xterm case is now producing process trees exactly like
} the case where there's an intermediate zsh, but the parent zsh is still
} not ignoring the TSTP.
 
More information:  Fooling around with "gdbterm" (I posted it to zsh-users
a while back) I managed to get zsh to stop and resume again (though the
mutt process got orphaned).  When zsh came back and I typed "fg" to try to
resume mutt, I got "no job control in this shell" which is pretty strange
as there had been job control a moment before.

That indicates to me that, in this bit of code from execpline() we're going
through the third branch:

		    if ((pid = fork()) == -1) {
			/* ... */
		    }
		    else if (pid) {
			/* ... */
		    else {
			close(synch[0]);
			entersubsh(Z_ASYNC, 0, 0);
			if (jobtab[list_pipe_job].procs)
			    setpgrp(0L, mypgrp = jobtab[list_pipe_job].gleader);
			close(synch[1]);
			kill(getpid(), SIGSTOP);
			list_pipe = 0;
			list_pipe_child = 1;
			opts[INTERACTIVE] = 0;
			break;
		    }

Which of course is the one thing Sven hasn't tried patching yet ... but I'm
not sure WHY zsh is going through the third branch.  All of Sven's patches
have been to the second branch.

What's odd is that over in the 6860 "Re: PATCH: loop killing" thread, zsh
DOESN'T get the signal when it's supposed to.  Maybe Sven's got the cases
in which zsh takes the second and third branches, reversed?

Or maybe I'm just completely confused, which is entirely likely by now.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

RE: 3.0.6-pre-5 problem and loop killing

[Andrej Borsenkow]

>
> Which of course is the one thing Sven hasn't tried patching yet ... but I'm
> not sure WHY zsh is going through the third branch.  All of Sven's patches
> have been to the second branch.
>
> What's odd is that over in the 6860 "Re: PATCH: loop killing" thread, zsh
> DOESN'T get the signal when it's supposed to.  Maybe Sven's got the cases
> in which zsh takes the second and third branches, reversed?
>

Looking a bit more closely on truss of the two cases reveal, that they are quite
different:

this is from xterm -e zsh (the case, when ^Z does not work):

bor@itsrm2:~%> fgrep 'fork
execve
SIGCLD' /tmp/foo
8323:   execve("/usr/bin/X11/xterm", 0x000000FFFFFEEC30, 0x000000FFFFFEEC40)
argc = 1
8323:   fork()                                          = 8324
8324:   fork()          (returning as child ...)        = 8323
8324:   sighold(SIGCLD)                                 = SIG_DFL
8324:   fork()                                          = 8326
8323:   signal(SIGCLD, 0x00000000004068E0)              = SIG_DFL
8326:   fork()          (returning as child ...)        = 8324
8326:   execve("/usr/lib/pt_chmod", 0x000000007FFEE07C, 0x000000007FFEEDD4)
argc = 2
8324:   sigrelse(SIGCLD)                                = SIG_DFL
8324:       Received signal #18, SIGCLD [default]
8324:         siginfo: SIGCLD CLD_EXITED pid=8326 uid=1 status=0x0000
8324:   signal(SIGCLD, SIG_DFL)                         = SIG_DFL
8324:   execve("/tools/bin/zsh", 0x000000007FFEE0CC, 0x000000000049CE90)  argc =
1
8324:   sigaction(SIGCLD, 0x000000007FFEEC60, 0x0000000000000000) = 0
8324:   fork()                                          = 8331
8331:   fork()          (returning as child ...)        = 8324
8331:   execve("/usr/bin/zcat", 0x0000000000502B28, 0x0000000000505780)  argc =
1
8324:       Received signal #18, SIGCLD, in sigsuspend() [caught]
8324:         siginfo: SIGCLD CLD_KILLED pid=8331 uid=0 status=0x0002
8323:       Received signal #18, SIGCLD, in poll() [caught]
8323:         siginfo: SIGCLD CLD_EXITED pid=8324 uid=61 status=0x0082
bor@itsrm2:~%>

Note, that zsh doe exactly one fork/execve for zcat

And here is the same for the simple case zsh started from other zsh:

bor@itsrm2:/tools/src/zsh-3.1.5-pws-23%>

fgrep 'fork
execve
SIGCLD' /tmp/zsh.1}
12558:  execve("/tools/bin/zsh", 0x000000FFFFFEECF0, 0x000000FFFFFEED00)  argc =
1
12558:  sigaction(SIGCLD, 0x000000007FFEED00, 0x0000000000000000) = 0
12558:  fork()                                          = 12559
12559:  fork()          (returning as child ...)        = 12558
12559:  execve("/usr/bin/zcat", 0x0000000000502D60, 0x00000000004FE5A0)  argc =
1
12558:      Received signal #18, SIGCLD, in sigsuspend() [caught]
12558:        siginfo: SIGCLD CLD_STOPPED pid=12559 uid=0 status=0x0018
12558:  fork()                                          = 12561
12561:  fork()          (returning as child ...)        = 12558
12558:      Received signal #18, SIGCLD [caught]
12558:        siginfo: SIGCLD CLD_STOPPED pid=12561 uid=0 status=0x0017
12558:      Received signal #18, SIGCLD, in sigsuspend() [caught]
12558:        siginfo: SIGCLD CLD_CONTINUED pid=12559 uid=0 status=0x0019
12558:      Received signal #18, SIGCLD, in sigsuspend() [caught]
12558:        siginfo: SIGCLD CLD_KILLED pid=12559 uid=0 status=0x0002
12558:      Received signal #18, SIGCLD [caught]
12558:        siginfo: SIGCLD CLD_CONTINUED pid=12561 uid=0 status=0x0019
12558:      Received signal #18, SIGCLD [caught]
12558:        siginfo: SIGCLD CLD_KILLED pid=12561 uid=0 status=0x0002
bor@itsrm2:/tools/src/zsh-3.1.5-pws-23%>

Here zsh forks once more. I have no idea, where lies the difference (apart from
these PGID/SID). Both are equally *not* login shells and source the same
scripts.

/andrej