bug-bash
[Top][All Lists]
Advanced

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

Re: bash 4.4 infinite loop while handling SIGTTIN


From: Pas
Subject: Re: bash 4.4 infinite loop while handling SIGTTIN
Date: Tue, 29 Nov 2016 10:32:43 +0100

Hello,

Thank you for the very fast reply, though I'd like to shamelessly ask
for more bits of your time.

I've strace'd all the involved processes (as far as I know), and all
were just getting the SIGTTINs, no one was sending SIGCONTs (
http://i.imgur.com/n5bUQVM.png - 25799 a bash process, and even the
bash (pid 7026) not in the picture that was just doing pselect(...) on
the terminal, the atom processes, and the bash process that goes
haywire ).

Also, if the default behavior for SIGTTIN is to stop, why bash isn't
stopping? How come the kernel isn't stopping it either? (And then if
not, where's the read() that should return EIO?)

(Even after stopping the parents (except 7026)
http://i.imgur.com/F4nOyKx.png bash was sending the SIGTTINs
http://i.imgur.com/i74SI0r.png .)

Thanks again!



On Mon, Nov 28, 2016 at 10:37 PM, Chet Ramey <address@hidden> wrote:
> On 11/28/16 4:11 AM, address@hidden wrote:
>> Hello,
>>
>> I'm using this package: bash_4.4-2ubuntu1_amd64.deb ( 
>> http://de.archive.ubuntu.com/ubuntu/pool/main/b/bash/bash_4.4-2ubuntu1_amd64.deb
>>  ), but the same behavior happens with bash 4.3.
>>
>> This seems to be the bug (feature?): 
>> http://stackoverflow.com/questions/13718394/what-should-interactive-shells-do-in-orphaned-process-groups
>>
>> I experience the bug when I launch Atom (a text editor so fancy it takes 
>> ages to start, maybe that's why it waits for an infinite loop ... 
>> https://github.com/atom/atom/issues/13317 ).
>>
>> Any thoughts on this? Is this something unavoidable by bash, or it's a bug? 
>> (Maybe it's a known bug?)
>
> Basically, the problem is how to run a interactive shell that reads from
> the tty when you're not a member of the foreground process group.  The bash
> strategy will get you the default behavior for SIGTTIN, which will stop
> the process.  The assumption is that there will be some parent process
> willing to handle the stop, not just automatically send a SIGCONT, and bash
> expects to be started with SIGTTIN set to the default disposition, not
> blocked.
>
> 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]