Date: Wed, 3 Dec 2008 22:52:34 -0800 From: Steve Watt <steve@Watt.COM> To: Nate Eldredge <neldredge@math.ucsd.edu> Cc: hackers@FreeBSD.org Subject: Re: tcsh loses the foreground process group? Message-ID: <20081204065234.GA28327@wattres.Watt.COM> In-Reply-To: <Pine.GSO.4.64.0812031541330.1597@zeno.ucsd.edu> References: <200812022328.mB2NSQa6049527@wattres.watt.com> <Pine.GSO.4.64.0812031541330.1597@zeno.ucsd.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Dec 03, 2008 at 03:58:36PM -0800, Nate Eldredge wrote: > On Tue, 2 Dec 2008, Steve Watt wrote: > > >In <20081201042037.GA43208@wattres.Watt.COM> Steve Watt wrote: [ tcsh 6.15.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 > > > >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. > > 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. Did the behavior change between 6.14.00 and 6.15.00? (Yeah, OK, I can go look myself.) OK, I went and looked. Answer: Yep, lots of additions of inappropriate things in backeval(). But it no longer has a 10K limit. > 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. Actually, there's another cost to making -F default: It makes hashstat rather less useful. OK, it's not like it's that useful to begin with, and is arguably a debugging function, but it's a side effect. As for a possible "why?" -F changes the hashstat behavior so? Probably because it's counting on not-quite-legal vfork() activity. Ugh. I'd managed to forget how unfun the code inside that shell is. I'll try to forget again.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081204065234.GA28327>