bug-readline
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-readline] readline + shell redirection + fish hangs


From: Chet Ramey
Subject: Re: [Bug-readline] readline + shell redirection + fish hangs
Date: Sat, 22 Apr 2017 20:12:15 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.0.1

On 4/21/17 12:29 PM, Alex Gaynor wrote:
> Hi Readline Maintainers!
> 
> This email describes a bug that occurs when readline is used in combination
> with the fish shell.
> 
> Initial diagnostic info:
> 
> readline 7.0.3, install with homebrew
> macOS 10.12.4
> Darwin agaynor-44227 16.5.0 Darwin Kernel Version 16.5.0: Fri Mar  3
> 16:52:33 PST 2017; root:xnu-3789.51.2~3/RELEASE_X86_64 x86_64
> fish, version 2.5.0
> 
> Ok, now to reproduce the bug:
> 
> ~ ❯❯❯ cat t.c
> #include <readline/readline.h>
> 
> int main() {
>     rl_initialize();
>     return 0;
> }
> ~ ❯❯❯ # Use the readline from homebrew, rather than the system one
> ~ ❯❯❯ clang -L /usr/local/opt/readline/lib/ -lreadline t.c
> ~ ❯❯❯ ./a.out | grep hi
> <hangs here>
> 
> 
> This works fine with the libEdit provided by macOS:
> 
> ~ ❯❯❯ clang -lreadline t.c
> ~ ❯❯❯ ./a.out | grep hi
> ~ ❯❯❯
> 
> It similarly works fine under bash.
> 
> Grabbing the process with lldb, shows it is hung in the following place:
> 
> * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
>   * frame #0: 0x00007fffa48b55ee libsystem_kernel.dylib`__ioctl + 10
>     frame #1: 0x00007fffa48b1569 libsystem_kernel.dylib`ioctl + 159
>     frame #2: 0x000000010eb7a362 libreadline.7.dylib`get_tty_settings + 54
>     frame #3: 0x000000010eb7a584
> libreadline.7.dylib`rltty_set_default_bindings + 57
>     frame #4: 0x000000010eb74a79 libreadline.7.dylib`rl_initialize + 200
>     frame #5: 0x000000010eb6ff84 a.out`main + 20
>     frame #6: 0x00007fffa4787235 libdyld.dylib`start + 1
>     frame #7: 0x00007fffa4787235 libdyld.dylib`start + 1

It hangs attempting to set the window size.  That's the result of a dummy
call that forces a check for readline being a background process (or a
member of a  background process group) before it tries to get the terminal
settings. libedit probably doesn't try this, and doesn't hang because Mac
OS X allows background processes to query the terminal settings.

It works in bash because bash runs all processes in a pipeline in the same
process group, and makes that process group the terminal's process group,
so all processes in the pipline are in the foreground.  This is basically
how job control works.

I don't know how fish behaves internally, but I suspect it runs the last
command in a pipeline in the shell's process group, and makes that process
group the terminal's foreground process group.  That puts the readline
call in a background process, and the kernel sends it the SIGSTOP when it
tries to set the window size.

The question is why fish doesn't respond to the stopped process by doing
something to the pipeline as a whole.  I don't know the answer.  In any
event, nothing will ever happen because the `grep' function will wait
forever for input from a stopped process.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]