Date: Wed, 14 Aug 2002 04:12:22 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Tim Robbins <tjr@FreeBSD.ORG> Cc: David Xu <bsddiy@yahoo.com>, <current@FreeBSD.ORG> Subject: Re: cvs commit: src/sys/kern kern_sig.c (fwd) Message-ID: <20020814033444.N29606-100000@gamplex.bde.org> In-Reply-To: <20020813235939.A10212@dilbert.robbins.dropbear.id.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 13 Aug 2002, Tim Robbins wrote:
> On Tue, Aug 13, 2002 at 06:14:38AM -0700, David Xu wrote:
>
> > --- Terry Lambert <tlambert2@mindspring.com> wrote:
> > > I did. It's still an order of operation problem in the kernel
> > > during fork(), as Bruce pointed out in a later posting (so me
> > > pointing it out here is probably redundant... 8-)).
Er, I didn't point out anything like this, and thought that it wasn't
a kernel problem. It's certainly not a problem at fork() time.
> > > I still think other code is going to have the problem, too, so
> > > changing su alone doesn't fix things. Better to not deliver
> > > the tty output stopped signal.
> >
> > Don't touch tty code, if you change, you'll break more code,
> > current problem is just because su forks a child process and
> > want to take over some job control work from shell, it is of
> > course not a easy job. the problem does not exist in STABLE
> > branch because su does not fork.
I think unwanted SIGTTOU's are just a sympto.
> What about chpass, vipw, and the other pw_edit() consumers? vipw
> works correctly wrt suspending with ^Z on 4.6-RELEASE, but does not
> on -CURRENT. As far as I can see, pw_edit()'s logic has not been changed.
Here is a trace for vi and vipw (but not the shell) from when I hit ^Z
in the editor to when the shell is given control because vi is bogusly
stopped again:
32898 vi 0.000010 CALL read(0,0x8118000,0xff)
32898 vi 8.642726 GIO fd 0 read 1 byte
"\^Z"
I waited about 10 seconds before hitting ^Z.
32898 vi 0.000036 RET read 1
32898 vi 0.007736 CALL break(0x813c000)
32898 vi 0.000008 RET break 0
32898 vi 0.000650 CALL sigaction(0x12,0x810684c,0x8106864)
32898 vi 0.000004 RET sigaction 0
32898 vi 0.002177 CALL poll(0xbfbff438,0x1,0)
32898 vi 0.000007 RET poll 0
32898 vi 0.000997 CALL poll(0xbfbff438,0x1,0)
32898 vi 0.000012 RET poll 0
32898 vi 0.000055 CALL write(0x1,0x8131000,0x5)
32898 vi 0.000017 GIO fd 1 wrote 5 bytes
"\^[[25d"
32898 vi 0.000067 RET write 5
32898 vi 0.000006 CALL sigaction(0x12,0x8106864,0)
32898 vi 0.000004 RET sigaction 0
32898 vi 0.000016 CALL write(0x1,0x8131000,0x8)
32898 vi 0.000005 GIO fd 1 wrote 8 bytes
"\^[[25;1H\r"
32898 vi 0.000024 RET write 8
32898 vi 0.000731 CALL ioctl(0x1,TIOCSETAW,0x811942c)
32898 vi 0.000017 RET ioctl 0
32898 vi 0.000510 CALL ioctl(0,TIOCSETAW,0xbfbff440)
32898 vi 0.000010 RET ioctl 0
32898 vi 0.001196 CALL kill(0,0x12)
vi does some setup and then kills the process group with SIGTSTP.
32897 vipw 5.363986 RET wait4 32898/0x8082
I waited about 5 seconds before hitting %.
32898 vi 0.000033 RET kill 0
vi regained control. Not sure if this is right.
32897 vipw 0.004388 CALL getpid
32897 vipw 0.000002 RET getpid 32897/0x8081
32898 vi 0.000019 CALL sigaction(0x12,0x810684c,0x8106864)
32898 vi 0.000004 RET sigaction 0
32897 vipw 0.005508 CALL kill(0x8081,0x12)
vipw does nothing much and then kills itself with SIGTSTP.
32898 vi 0.000064 CALL ioctl(0x1,TIOCGETA,0xbfbff3a0)
32898 vi 0.000003 RET ioctl 0
32898 vi 0.002309 CALL ioctl(0x1,TIOCGWINSZ,0xbfbff3f8)
32898 vi 0.000003 RET ioctl 0
32898 vi 0.007648 CALL ioctl(0x1,TIOCSETAW,0x8119458)
This ioctl blocks and the shell gains control. Apparently vi is still
in the background at this point, but it shouldn't be... Or maybe which
process is in the background depends on races, and it is normal for
vi to block here (please check on RELENG_4 if you have it handy), and
the problem is simply a missing or extra signal that results in vi not
being put back in the foreground.
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020814033444.N29606-100000>