Re: [Bug-readline] readline bug with backgrounded process?

[Chet Ramey]

On 4/21/14, 10:05 AM, Thomas Klausner wrote:
> On Mon, Apr 14, 2014 at 10:06:44AM -0400, Chet Ramey wrote:
>> On 4/13/14, 6:46 PM, Thomas Klausner wrote:
>>> Hi!
>>>
>>> Since a couple of weeks ago, gnucash as installed by pkgsrc on
>>> NetBSD-6.99.40/amd64 doesn't start in the background any longer for
>>> me.
>>>
>>> It looks like this (in zsh):
>>
>> It looks like gnucash, when linked with readline, attempts to write to the
>> controlling terminal and gets a SIGTTOU.
>>
>>>> gnucash &
>>> [1] 8065
>>>>
>>> [1]  + suspended (tty output)  gnucash
>>>> fg
>>> [1]  + continued  gnucash
>>> Found Finance::Quote version 1.18
>>> (runs)
>>
>> And it appears that the above message about `Quote version 1.18' is what it
>> tries to write.
>>
>> I suppose it could be readline reacting to the SIGTTOU and calling the
>> signal hook, but I doubt that python has a signal hook assigned.  If
>> there's no signal hook, readline just passes the signal through to the
>> calling application.  In the case of SIGTTOU, unless the calling
>> application is ignoring it, the process will be stopped.
>>
>> It might be useful to get a stack traceback from the gnucash process
>> when it gets a SIGTTOU.
> 
> I've installed a signal handler catching SIGTTOU and calling abort()
> in the gnucash binary.

Well, this tells me that this particular function is behaving as it should.
The assumption here is that an application including readline is most often
launched from a job-control shell that does appropriate process group
management.  The assumption is also that the shell does command line
editing and modifies the terminal's settings when it has control of the
controlling terminal.

Readline saves and restores the terminal settings because it modifies them
in order to do editing.  There's an obvious race condition here: if a
backgrounded application using readline fetches the tty settings after the
calling shell has modified them to read the next command line, bad things
will happen when the application is eventually brought to the foreground
and restores the (bogus) tty settings when it exits.  The call to
ioctl is one that will deliver a SIGTTOU if the process isn't in the
foreground, so it will presumably fetch the right tty settings once it's
resumed.

The reason I didn't bring this up earlier is that this code has been in
readline for years (literally; I stopped looking at bash-3.2, but it's been
there for at least that long).

There's nothing keeping an application from ignoring SIGTTOU.  Maybe the
difference is that previous gnucash versions used to ignore SIGTTOU.

Chet

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