>Number:         36714
>Category:       kern
>Synopsis:       bringing a background process to the foreground seems to stall the process
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Aug 01 00:25:00 +0000 2007
>Originator:     oster@netbsd.org
>Release:        NetBSD 4.99.25
>Organization:
>Environment:
System: NetBSD scrooge 4.99.25 NetBSD 4.99.25 (SCROOGE) #0: Tue Jul 31 12:10:05 CST 2007 oster@scrooge:/u1/builds/build21/src/sys/arch/i386/compile/SCROOGE i386
Architecture: i386
Machine: i386
>Description:
	Various programs have issues when started in the background and then 
brought to the foreground.  The problem was first found with emacs20 from 
pkgsrc, but has since been easy to replicate with programs like 'top'
and 'systat'.  The problem is seen on at least i386, amd64, and macppc. 
Kernels 4.99.20 and before appear unaffected.  Kernels 4.99.23 and later 
have the issue.  Shell seems to be irrelevant (csh, tcsh, and sh all have
the same behaviour).

What happens is:

oster@scrooge-49> top &
[1] 5263
oster@scrooge-50> 
[1]  + Stopped (tty output)   top
fg
top


[hang]
^C^C^C
User defined signal 1
oster@scrooge-51> 

At the "[hang]" part, 'top' is simply frozen, and does not respond to 
anything, including CTRL-c.  The simplest way to "recover" is to 
send the 'top' process a signal via:  kill -s USR1 5263
For 'emacs -nw &', doing a 'fg' afterwards will result in the same 'hang',
but a CTRL-c will allow the process to continue mostly as normal (it seems
to be missing the top menu bar for some reason?).

The behaviour from 'systat' is even more interesting.  We see:

oster@scrooge-53> systat iostat &
[1] 554
oster@scrooge-54> 
[1]  + Stopped (tty output)   systat iostat
fg
systat iostat


^CSegmentation fault
oster@scrooge-55> 

but, unfortunately, it doesn't seem to want to dump a core file.

The WCHAN for these 'hung' processes appears to be 'ttybg' in all cases.

'kdump' of a trace indicates that this is where they sit and "wait" for
a signal or something to wake them up out of the 'hang'.

  1639      1 top      1185919736.184278560 RET   ioctl 0
  1639      1 top      1185919736.184316836 CALL  ioctl(1,TIOCSETAW,0x8051c60)
  1639      1 top      1185919736.184319351 GIO   fd 1 wrote 44 bytes
       "\0\^C\0\0\^C\0\0\0\0[\0\0\M-C\^D\0\0\^D\^[\0\b\^W\^U\^R\0\^C\0\^Z\^Y\
        \^Q\^S\^V\^O\^A\0\M^?\0\0\M^V\0\0\0\M^V\0\0"
  1639      1 top      1185919918.384652443 RET   ioctl RESTART
  1639      1 top      1185919918.384660545 PSIG  SIGUSR1 SIG_DFL

At least 'top' and 'emacs' show this same call sequence.


>How-To-Repeat:
	top &
	fg

	systat iostat &
	fg

	some_other_program_that_blocks_needing_a_tty &
	fg


>Fix:
	Unknown.