On Fri, Dec 02, 2005 at 10:08:59AM -0800, Matthew Dillon wrote: > :Hello. > :After the following commit, stopping a user process with SIGSTOP > :does not give control to the shell: > :http://leaf.dragonflybsd.org/mailarchive/commits/2005-11/msg00109.html > :It only happens with a program which does fork() inside it. Here's > :a simple program to demonstrate this. > : > :$ gcc -g -Wall a.c && ./a.out cat > :(press ctrl+Z here, and it accepts no other signals until you send > :SIGCONT to the child process from another screen) > : > :`ps' command shows that the stuck processes are marked as "TL+" > :(meaning that they didn't give up even after having been stopped?). > > Ah ha! I have reproduced it. I was running './a.out cat' separately, > from csh, while you were running it from /bin/sh. > > When I changed over to /bin/sh the problem reproduced. > > I'll get it fixed today, hopefully soon.
While this has been fixed, I realized that I overlooked another similar problem; try running vipw, suspend it with ctrl-Z and continue with `fg'; the shell immediately reports that vipw has been suspended(processes are marked as `TL' by ps command); another `fg' seems to continue it, but vi(or whatever editor invoked by vipw) doesn't handle the screen properly, even though it's responding to the keystrokes. Attached is a small code fragment that demonstrates the problem. BTW, it behaves differently on -CURRENT and 1.2.6-RELEASE; on -CURRENT, waitpid() returns after `fg' command followed by a ctrl-Z, while on 1.2.6-RELEASE it never returns when suspended or continued. Without WUNTRACED flag, the code seems to work the same way on both versions of the OS. Too bad I couldn't find it before the new release.
