Date: Wed, 3 Dec 2008 15:58:36 -0800 (PST) From: Nate Eldredge <neldredge@math.ucsd.edu> To: Steve Watt <steve@watt.com> Cc: hackers@FreeBSD.org Subject: Re: tcsh loses the foreground process group? Message-ID: <Pine.GSO.4.64.0812031541330.1597@zeno.ucsd.edu> In-Reply-To: <200812022328.mB2NSQa6049527@wattres.watt.com> References: <200812022328.mB2NSQa6049527@wattres.watt.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2 Dec 2008, Steve Watt wrote: > In article <20081201042037.GA43208@wattres.Watt.COM> you write: > [ ... ] >> I'm running 6-STABLE (6.4-PRE as of 24 Nov right now), tcsh 6.15.00, which >> shows >> >> tcsh 6.15.00 (Astron) 2007-03-03 (i386-intel-FreeBSD) options wide,nls,dl,al,kan,sm,rh,color,filec >> >> as $version. >> >> The symptom is that when I do a long-ish running task inside a `` expansion >> that I then ^C, nobody gets the foreground process group... I never get >> a prompt back after the ^C, and ^T gets me >> >> load: 0.27 no foreground process group > > [ ... ] > >> One portable reproduction: >> # cd /usr/src >> # less `egrep -lir '^Foo.*baz' *` >> ^Cload: 0.02 no foreground process group >> >> (I typed ^C ^T) >> >> SIGKILL to the shell seems to be the only way to get things back to >> normal. > > I've gotten one "me too", which indicated that SIGHUP to the shell > will also make it go away, but does not solve the problem. > > I've got another FreeBSD machine available that was running tcsh > 6.14.00, and it does _NOT_ display the problem. When I build > 6.15.00 on that same box (/usr/src is more up to date than the > install right now), that does fail. > > Thus I'm pretty comfortable saying that it's a tcsh bug of some > sort, and probably a regression. Hopefully this can be fixed > (PR being filed now) before 6.4 releases... Thanks for the report. It looks like this is yet another manifestation of a problem in tcsh, where it does inappropriate things in a vfork'ed subshell. In my tests, running tcsh with -F (which causes it to use fork instead of vfork) causes the problem to go away. It is also present in 7.0-RELEASE and probably all later versions. There are several open bugs related to this problem, but so far they do not seem to have attracted the interest of any committers. Among them are: bin/41297 bin/52746 bin/125185 amd64/128259 bin/129378 (which you just opened) The fix is simple: make -F the default. There is a minor performance penalty, but that's a small price to pay for correct behavior. A more involved fix would be to make tcsh not do inappropriate things after vfork (modifying global variables), or at least clean up before exiting, but IMHO that is less clean; vfork really shouldn't be used here at all. -- Nate Eldredge neldredge@math.ucsd.edu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0812031541330.1597>