From jsquyres at cisco.com  Tue Mar 18 22:09:33 2008
From: jsquyres at cisco.com (Jeff Squyres)
Date: Tue, 18 Mar 2008 16:09:33 -0400
Subject: lame tcsh bug report
Message-ID: <687BD954-9FCB-4675-AF37-A19E2C99014F@cisco.com>

Greetings all.  I'm a long-time tcsh user, first time caller.

I have a fairly lame bug report/inquiry that is sparse on details  
mainly because the bug behavior occurs with low frequency and seems to  
be fairly random.  Specifically: although I've seen this bug for a  
year or two, I have not been able nail down exactly what causes it.   
Here's what I know:

- The bad behavior is that *sometimes* when you hit Ctrl-C in the  
middle of a command line, tcsh silently dies (rather than aborting the  
current line and going to a new/blank command prompt).  This is fairly  
annoying, but it happens so infrequently that it is difficult to  
gather specific information on exactly what causes the problem.   
Attempts to deliberately create the bug behavior have always been  
unsuccessful.  :-(

- I am using the built-in tcsh on OS X; I have seen this behavior on  
both Leopard (current release) and Tiger (previous release).  tcsh is  
my login shell.  tcsh on Leopard reports:

% tcsh --version
tcsh 6.14.00 (Astron) 2005-03-25 (i386-apple-darwin) options  
wide,nls,dl,al,kan,sm,rh,color,filec

I no longer have access to Tiger systems to see what version of tcsh  
they ship.

- tcsh does not appear to dump core when this happens; it just  
silently exits with no error message.  So I really have no further  
information on what is going wrong inside tcsh.

- The problem appears to occur only after you've been using tcsh for  
"a while" (I wish I could be more precise on this :-\ ).

- There seems to need to be characters on the command line for this  
problem to occur; I'm almost positive that I've never seen this  
problem occur when ctrl-C was typed as the first character on the  
command line.

- I have not strictly noted whether the cursor is always at the end of  
the line or somewhere in the middle of the line.  Twice earlier this  
morning (which is an unusually high frequency, and prompted me to post  
to this list), I had tcsh die when the cursor was at the end of the  
line.

- The bad behavior seems to *usually* happen when I've used up-arrow  
or ctrl-P to get to a previous command.

Again, I apologize for the lack of detail.  I'm posting to see if  
anyone else has ever seen this issue, and to see if anyone can suggest  
ways that I could get more information that would be helpful to the  
developers.

FWIW: I just downloaded the source for 6.15 and looked at the  
changelog; there doesn't appear to be anything in there about fixes  
for this behavior.  I also did a few google searches on the mailing  
list archives but didn't see anything related to this issue.

Thanks for your time.

-- 
Jeff Squyres
Cisco Systems


From don.estabrook at gmail.com  Tue Mar 25 04:39:40 2008
From: don.estabrook at gmail.com (don.estabrook at gmail.com)
Date: Mon, 24 Mar 2008 21:39:40 -0500 (CDT)
Subject: lame tcsh bug report
Message-ID: <200803250239.m2P2degB020043@hornet9.pcs.mot.com>

Hello Jeff,

> I'm posting to see if anyone else has ever seen this issue...

I've been using tcsh for fairly long time too, and I can say that I've
seen some elusive symptoms that are at least similar to yours - although
I don't remember just now whether they were related to hitting Ctrl-C.
Like you, I normally see the problems rarely enough, and my memory is
bad enough, that I haven't been able to find a pattern to how I elicited
them.

One question: Do you use "vi" or "emacs" key bindings?  In my case, I
use vi mode ("bindkey -v"), and I have been able to find one very
repeatable problem.  Here's a quick summary:

  - Start a shell.
  - Type a few commands to get the history loaded.
  - Hit <ESC> to enter command mode, then '?' to search backwards
    through history.  Enter a search string at the '?' prompt that can
    be found in one of the commands that's in the history, then hit
    <CR>.  It should find the command, no problem, and the cursor should
    be positioned at the end of that command.
  - Hit 'n' to find the next match *1 more time* than the number of
    commands that should match.  (So if you searched for something that
    only appears once in the history list, you only need to hit 'n'
    once.)

    Result: The earliest matching command is still displayed, and the
    cursor is still at the end of the line, but things are a bit wacko.
    If you try to navigate within the line, with 'b' to go back a word,
    for example, you'll find that the cursor goes to the wrong place.
    It's as if there's really nothing there underneath -- hitting '$'
    goes to the beginning of the line instead of the end.

Very sorry if this has no relevance to your problem, but the reason I
mention it is that I think it has been one of the things leading up to
*some* of my random exits/crashes.  If you don't recognize that it's in
this state, and you try to carry on fiddling with what you see on the
screen, you can get unexpected results, including exits and seg-faults.
(Doing a Ctrl-D with the intention of getting a completion list can be
interpreted as EOF, for example.)  Interestingly, I often use Ctrl-C to
get out of that command quickly, which sets things right again for the
next prompt.  ;)

I don't use emacs mode at all, so I can't say if there's an equivalent
situation there.  And I haven't had time to look at the code to figure
out what's happening, so I don't have any appreciation for how hard it
would be to stumble into this from other contexts (like some emacs
commands).

I can also remember a few cases where browsing the history list has
produced some unprintable garbage in place of valid commands.  Like with
the situation above, when I see this, I have to be careful to kill that
command straightaway, because it's a sign that things are very fragile.
Unfortunately, I haven't figured out what gets me into that state.

Sorry if this turns out to be off-topic.

Don Estabrook


From jsquyres at cisco.com  Tue Mar 25 14:07:15 2008
From: jsquyres at cisco.com (Jeff Squyres)
Date: Tue, 25 Mar 2008 08:07:15 -0400
Subject: lame tcsh bug report
In-Reply-To: <200803250239.m2P2ddkD020040@hornet9.pcs.mot.com>
References: <200803250239.m2P2ddkD020040@hornet9.pcs.mot.com>
Message-ID: <985F5062-1D6C-43DE-8662-F9C1F4955F77@cisco.com>

Don --

Thanks for your note.  I'm using the emacs bindings, so I don't know  
if the issues are directly related or not.  It's more data, though,  
and that's good!


On Mar 24, 2008, at 10:39 PM, don.estabrook at gmail.com wrote:
> Hello Jeff,
>
>> I'm posting to see if anyone else has ever seen this issue...
>
> I've been using tcsh for fairly long time too, and I can say that I've
> seen some elusive symptoms that are at least similar to yours -  
> although
> I don't remember just now whether they were related to hitting Ctrl-C.
> Like you, I normally see the problems rarely enough, and my memory is
> bad enough, that I haven't been able to find a pattern to how I  
> elicited
> them.
>
> One question: Do you use "vi" or "emacs" key bindings?  In my case, I
> use vi mode ("bindkey -v"), and I have been able to find one very
> repeatable problem.  Here's a quick summary:
>
>  - Start a shell.
>  - Type a few commands to get the history loaded.
>  - Hit <ESC> to enter command mode, then '?' to search backwards
>    through history.  Enter a search string at the '?' prompt that can
>    be found in one of the commands that's in the history, then hit
>    <CR>.  It should find the command, no problem, and the cursor  
> should
>    be positioned at the end of that command.
>  - Hit 'n' to find the next match *1 more time* than the number of
>    commands that should match.  (So if you searched for something that
>    only appears once in the history list, you only need to hit 'n'
>    once.)
>
>    Result: The earliest matching command is still displayed, and the
>    cursor is still at the end of the line, but things are a bit wacko.
>    If you try to navigate within the line, with 'b' to go back a word,
>    for example, you'll find that the cursor goes to the wrong place.
>    It's as if there's really nothing there underneath -- hitting '$'
>    goes to the beginning of the line instead of the end.
>
> Very sorry if this has no relevance to your problem, but the reason I
> mention it is that I think it has been one of the things leading up to
> *some* of my random exits/crashes.  If you don't recognize that it's  
> in
> this state, and you try to carry on fiddling with what you see on the
> screen, you can get unexpected results, including exits and seg- 
> faults.
> (Doing a Ctrl-D with the intention of getting a completion list can be
> interpreted as EOF, for example.)  Interestingly, I often use Ctrl-C  
> to
> get out of that command quickly, which sets things right again for the
> next prompt.  ;)
>
> I don't use emacs mode at all, so I can't say if there's an equivalent
> situation there.  And I haven't had time to look at the code to figure
> out what's happening, so I don't have any appreciation for how hard it
> would be to stumble into this from other contexts (like some emacs
> commands).
>
> I can also remember a few cases where browsing the history list has
> produced some unprintable garbage in place of valid commands.  Like  
> with
> the situation above, when I see this, I have to be careful to kill  
> that
> command straightaway, because it's a sign that things are very  
> fragile.
> Unfortunately, I haven't figured out what gets me into that state.
>
> Sorry if this turns out to be off-topic.
>
> Don Estabrook


-- 
Jeff Squyres
Cisco Systems


From jsquyres at cisco.com  Mon Mar 31 21:05:33 2008
From: jsquyres at cisco.com (Jeff Squyres)
Date: Mon, 31 Mar 2008 14:05:33 -0400
Subject: lame tcsh bug report
In-Reply-To: <985F5062-1D6C-43DE-8662-F9C1F4955F77@cisco.com>
References: <200803250239.m2P2ddkD020040@hornet9.pcs.mot.com>
	<985F5062-1D6C-43DE-8662-F9C1F4955F77@cisco.com>
Message-ID: <DF739DE3-0014-4B49-8C14-F10085A8E525@cisco.com>

By total luck today, I got a simple reproducer!!  (/me does a happy  
dance)

The problem seems to have something to do with background processes,  
the "noclobber" environment variable / tcsh setting, and redirecting  
output to /dev/null.  Here's my reproducer (run with no .tcshrc  
or .cshrc, just to be as clean as possible) on a MacBook Pro, OS X  
10.5.2 with /bin/tcsh (the tcsh that ships with Leopard):

-----
set noclobber
sleep 500 > /dev/null
<ctrl-z>
<ctrl-c>
-----

Notes:

1. it has something to do with noclobber and redirecting to /dev/null
2. redirecting to other files does not cause the problem
3. "sleep 500 > /dev/null &" does not cause the problem; you must ctrl-z

Using this information, I can get a core dump on OS X:

-----
[rtp-jsquyres-8712:~] jsquyres% tcsh
[rtp-jsquyres-8712:~] jsquyres% set noclobber
[rtp-jsquyres-8712:~] jsquyres% sleep 500 > /dev/null
^Z
Suspended
[rtp-jsquyres-8712:~] jsquyres% <hit ctrl-c here>Segmentation fault  
(core dumped)
[rtp-jsquyres-8712:~] jsquyres%
-----

But unfortunately it is not helpful -- I'm guessing the binary was  
stripped?

I tried building tcsh 6.14 myself and running it (just "./configure;  
make; ./tcsh"), but it seems to hang on most commands (e.g., it even  
hangs after running ls -- it never returns to a shell prompt).

I build 6.15 myself and ran it (just "./configure; make; ./tcsh"), and  
the same segv problem does not seem to occur.  However, I don't know  
if that means if the bug was fixed or if Apple built tcsh a different  
way.

Does anyone have any suggestions?



On Mar 25, 2008, at 8:07 AM, Jeff Squyres wrote:
> Don --
>
> Thanks for your note.  I'm using the emacs bindings, so I don't know
> if the issues are directly related or not.  It's more data, though,
> and that's good!
>
>
> On Mar 24, 2008, at 10:39 PM, don.estabrook at gmail.com wrote:
>> Hello Jeff,
>>
>>> I'm posting to see if anyone else has ever seen this issue...
>>
>> I've been using tcsh for fairly long time too, and I can say that  
>> I've
>> seen some elusive symptoms that are at least similar to yours -
>> although
>> I don't remember just now whether they were related to hitting Ctrl- 
>> C.
>> Like you, I normally see the problems rarely enough, and my memory is
>> bad enough, that I haven't been able to find a pattern to how I
>> elicited
>> them.
>>
>> One question: Do you use "vi" or "emacs" key bindings?  In my case, I
>> use vi mode ("bindkey -v"), and I have been able to find one very
>> repeatable problem.  Here's a quick summary:
>>
>> - Start a shell.
>> - Type a few commands to get the history loaded.
>> - Hit <ESC> to enter command mode, then '?' to search backwards
>>   through history.  Enter a search string at the '?' prompt that can
>>   be found in one of the commands that's in the history, then hit
>>   <CR>.  It should find the command, no problem, and the cursor
>> should
>>   be positioned at the end of that command.
>> - Hit 'n' to find the next match *1 more time* than the number of
>>   commands that should match.  (So if you searched for something that
>>   only appears once in the history list, you only need to hit 'n'
>>   once.)
>>
>>   Result: The earliest matching command is still displayed, and the
>>   cursor is still at the end of the line, but things are a bit wacko.
>>   If you try to navigate within the line, with 'b' to go back a word,
>>   for example, you'll find that the cursor goes to the wrong place.
>>   It's as if there's really nothing there underneath -- hitting '$'
>>   goes to the beginning of the line instead of the end.
>>
>> Very sorry if this has no relevance to your problem, but the reason I
>> mention it is that I think it has been one of the things leading up  
>> to
>> *some* of my random exits/crashes.  If you don't recognize that it's
>> in
>> this state, and you try to carry on fiddling with what you see on the
>> screen, you can get unexpected results, including exits and seg-
>> faults.
>> (Doing a Ctrl-D with the intention of getting a completion list can  
>> be
>> interpreted as EOF, for example.)  Interestingly, I often use Ctrl-C
>> to
>> get out of that command quickly, which sets things right again for  
>> the
>> next prompt.  ;)
>>
>> I don't use emacs mode at all, so I can't say if there's an  
>> equivalent
>> situation there.  And I haven't had time to look at the code to  
>> figure
>> out what's happening, so I don't have any appreciation for how hard  
>> it
>> would be to stumble into this from other contexts (like some emacs
>> commands).
>>
>> I can also remember a few cases where browsing the history list has
>> produced some unprintable garbage in place of valid commands.  Like
>> with
>> the situation above, when I see this, I have to be careful to kill
>> that
>> command straightaway, because it's a sign that things are very
>> fragile.
>> Unfortunately, I haven't figured out what gets me into that state.
>>
>> Sorry if this turns out to be off-topic.
>>
>> Don Estabrook
>
>
> -- 
> Jeff Squyres
> Cisco Systems
>
> _______________________________________________
> Tcsh-Bugs mailing list
> Tcsh-Bugs at mx.gw.com
> http://mx.gw.com/mailman/listinfo/tcsh-bugs


-- 
Jeff Squyres
Cisco Systems


From christos at zoulas.com  Mon Mar 31 21:41:28 2008
From: christos at zoulas.com (Christos Zoulas)
Date: Mon, 31 Mar 2008 14:41:28 -0400
Subject: lame tcsh bug report
In-Reply-To: <DF739DE3-0014-4B49-8C14-F10085A8E525@cisco.com>
	from Jeff Squyres (Mar 31,  2:05pm)
Message-ID: <20080331184128.7805356552@rebar.astron.com>

On Mar 31,  2:05pm, jsquyres at cisco.com (Jeff Squyres) wrote:
-- Subject: Re: lame tcsh bug report

| By total luck today, I got a simple reproducer!!  (/me does a happy  
| dance)
| 
| The problem seems to have something to do with background processes,  
| the "noclobber" environment variable / tcsh setting, and redirecting  
| output to /dev/null.  Here's my reproducer (run with no .tcshrc  
| or .cshrc, just to be as clean as possible) on a MacBook Pro, OS X  
| 10.5.2 with /bin/tcsh (the tcsh that ships with Leopard):

Hmm, I have to find an OS/X box... Works fine on linux and BSD.

christos