On Tue, 2 Dec 2008, Steve Watt wrote:

In article <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to