Bug 129378 - csh(1) / tcsh(1) loses foreground process group [regression]
Summary: csh(1) / tcsh(1) loses foreground process group [regression]
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-12-02 23:40 UTC by Steve Watt
Modified: 2017-12-31 22:35 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Steve Watt 2008-12-02 23:40:01 UTC
tcsh 6.15.00 appears to lose track of the foreground process group when SIGINT comes in during backquote expansion.  This problem does not show up with tcsh 6.14.00.

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

Sending SIGCHLD and/or SIGCONT to the tcsh doesn't seem to make any
difference at all.

The tcsh is sitting in "pause" WCHAN, which seems sensible.  A truss
on tcsh reveals (oddly enough) that it's sitting in sigsuspend().
Sending it signals makes it loop through a wait4() call and go back into
sigsuspend().

It happens running either as root (from sudo) or as a regular user.  It
happens under xterm, under ssh sessions, and on a direct console login.

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, and it does in your shell.

I also got a "me too" from my posting on -hackers about this which stated that a SIGHUP would also make the shell go away.

Fix: 

Use tcsh 6.14.00 (probably not a desirable workaround).
How-To-Repeat: % cd /usr/src
% less `egrep -lir '^Foo.*baz' *`
^C^T
Comment 1 Nate Eldredge 2008-12-04 00:01:14 UTC
The problem goes away when tcsh is run with -F, and thus this bug is 
probably related to bin/125185 et al.  tcsh under some conditions will 
modify global state after vfork(), breaking things when the parent runs 
again.  -F causes it to use fork() instead of vfork() and then all is 
well.  IMHO -F should be made the default.

-- 

Nate Eldredge
neldredge@math.ucsd.edu
Comment 2 Nate Eldredge 2008-12-04 00:43:08 UTC
This is incorporated into bin/129405.

-- 

Nate Eldredge
neldredge@math.ucsd.edu
Comment 3 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:58:35 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped