Re: tcsh loses the foreground process group?
On Wed, Dec 03, 2008 at 03:58:36PM -0800, Nate Eldredge wrote: > On Tue, 2 Dec 2008, Steve Watt wrote: > > >In <[EMAIL PROTECTED]> 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. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcsh loses the foreground process group?
On Wed, 3 Dec 2008, Nate Eldredge wrote: 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) I have opened bin/129405 as an omnibus PR for these problems. -- 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]"
Re: tcsh loses the foreground process group?
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]"
Re: tcsh loses the foreground process group?
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... -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.5" / 37N 20' 15.3" Internet: steve @ Watt.COM Whois: SW32-ARIN Free time? There's no such thing. It just comes in varying prices... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
tcsh loses the foreground process group?
(Please don't cc: me on replies, I can usually keep up with -hackers.) I've run into this about 5 or 6 times recently, and it seems to have survived the last couple of world updates. 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 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 to normal. I'm not sure how to isolate it further - it seems likely that this is a bug in the kernel, rather than in tcsh, but the session management stuff is pretty hairy in both places. Does anyone have debugging thoughts? -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.5" / 37N 20' 15.3" Internet: steve @ Watt.COM Whois: SW32-ARIN Free time? There's no such thing. It just comes in varying prices... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
