tcsh loses the foreground process group?

[Nate Eldredge]

On Tue, 2 Dec 2008, Steve Watt wrote:

> In article <20081201042037.GA43208 at 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 at math.ucsd.edu