lame tcsh bug report

[Jeff Squyres]

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