top not restoring terminal echo/icanon correctly
Carl Johnson
carlj at peak.org
Tue Apr 17 22:47:13 UTC 2012
Jeremy Chadwick <freebsd at jdc.parodius.com> writes:
> On Tue, Apr 17, 2012 at 12:51:15PM -0700, Jeremy Chadwick wrote:
>> On Tue, Apr 17, 2012 at 11:22:42AM -0700, Jeremy Chadwick wrote:
>> > (Please keep me CC'd as I'm not subscribed to the list)
>> >
>> > I'd like to request that folks running RELENG_8 (and RELENG_9, though I
>> > do not use it) please check the behaviour of their terminal after each
>> > of following commands are run (check terminal after each command):
>> >
>> > top -a (press "q" after 1 screen refresh)
>> > top -b
>> >
>> > If you find that your input characters in your shell aren't being echo'd
>> > back after one of the above commands, blindly type "stty icanon echo"
>> > and hit <Enter> and things should be back to normal.
>> >
>> > What I'm looking for is confirmation from others of the problem.
>> >
>> > Also very important: please provide uname -a output, specifically world
>> > rebuild date. It greatly matters, because a commit was recently done
>> > where now -b functions fine (was previously busted in this way), but now
>> > -a behaves like -b did. So src/world date matters.
>> >
>> > All of this is documented in PR 161739. I urge anyone experiencing this
>> > problem to read that PR in full, as I spent many hours today writing a
>> > debug routine to confirm that top is sometimes not calling tcsetattr()
>> > with the original terminal parameters when it exits, and what the
>> > condition seems to be.
>> >
>> > http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/161739
>> >
>> > Finally, if anyone want to tackle the problem (work out the logic bug
>> > that is in there which causes it), please be my guest. I have other
>> > things going on right now (doctors appointments) so I don't have as much
>> > time as I'd like.
>> >
>> > Thanks everyone.
>>
>> Thanks to all those who have responded, including kib at .
>>
>> The problem is very odd and appears specific to the bash shell, but
>> only "somewhat". Below is a part of what I sent kib@ on the matter.
>> A chart showing what I've found:
>>
>> Location Username TERM Shell bug?
>> =============================================================
>> VGA console root cons25 /bin/csh no
>> VGA console jdc cons25 /usr/local/bin/bash no
>> SSH (PuTTY) root xterm /bin/csh no
>> SSH (PuTTY) jdc xterm /bin/csh no
>> SSH (PuTTY) jdc xterm /usr/local/bin/bash yes
>> =============================================================
>>
>> In the last case (and only that case): if I move my dotfiles (.bashrc
>> and .bash_profile) aside and log in (SSH), top behaves normally.
>> Naturally this made me think "something is wonky with my dotfiles!"...
>>
>> But the problem *doesn't* happen if my dotfiles are intact and I
>> log in via VGA console (cons25) as myself with a bash shell. So it's
>> almost like there's some bizarre combination of things that causes this
>> problem.
>>
>> I'll continue to try and narrow it down.
>
> Boy this is a weird one.
>
> In my .bashrc I've been using the following statement to show all
> arguments and set the update interval to 1 second:
>
> export TOP="-a -s 1"
>
> Removing this completely and logging back in results in no problems
> when running "top" in any way (top -a, top -s 1, or top -a -s 1).
>
> However, the problem I describe with icanon/echo never getting restored
> rears its ugly head when running "top -a -b", but only under bash
> (with no dotfiles too). It never happens under csh.
>
> I can also reproduce this on VGA console when logged in (regardless of
> user), e.g. log in as root (get csh shell), run bash, "top -a -b", bam,
> issue happens.
>
> I don't know what's different about the two shells at this level that
> would cause oddities like this, but um, yeah..... *blink*
I checked /bin/sh and it shows the same problem as bash, but pdksh and
csh don't have any problem. Running stty -a shows that all have -icanon
and -echo after runnin top, but csh and pdksh appear to ignore those
settings. I have tried in xterm and console and it doesn't make any
difference. I tested both on 8.1-RELEASE and 9.0-RELEASE (without ksh).
These are unmodified systems with GENERIC kernels, so the problem is not
new.
--
Carl Johnson carlj at peak.org
More information about the freebsd-stable
mailing list