Re: [PATCH bisected regression] input_available_p() sometimes says 'no' when it should say 'yes'

Peter Hurley
2015-05-04T16:32:15Z

On 05/04/2015 08:24 AM, Michael Matz wrote:
> Hi,
>
> On Fri, 1 May 2015, Peter Hurley wrote:
>
>> I don't think this a real bug, in the sense that pty i/o is not
>> synchronous, in the same way that tty i/o is not synchronous.
>
> Here's what I wrote internally about my speculations about this being a
> bug or not:
>
>>> I also never hit it with pipes (remove the USEPTY define), also not on
>>> sle12, so it must be some change specific to the pty implementation.
>>>
>>> Now, all of this is of course unspecified. There are two asynchronous
>>> processes involved, and a buffered tube between them. Just because
>>> one process filled one end of the tube (the breakpoint was hit)
>>> doesn't mean the contents have to appear at that instant at the other
>>> end. So the change in behaviour in sle12 is not a genuine bug. It
>>> _might_ be an unintented change, though, that's why kernel people
>>> should comment on this. If there are no terribly good reasons for
>>> this change I'd consider it a quality-of-implementation regression in
>>> sle12.
>
> So, I'd accept this being declared a non-bug, but it is certainly a change
> in behaviour that's visible for our debugger team.
>
>> However, that said, if this is a regression (regression as in "it broke
>> something that used to work", not regression as in "this new thing I'm
>> writing doesn't behave the way I want it to" :) )
>>
>> Help me understand the use-case here: are you using pty i/o to debug the
>> debugger?
>
> Nic is working on the Cobol debugger, but I think this pty i/o is rather a
> part of the normal interaction between a debugged Cobol process and the
> debugger; that's just a theory, Nic is authorative here. But this change
> in behaviour _did_ result in real testsuite regressions, so it's not
> something that he wanted to write from scratch.

I'd like to understand why the debugger cares about when pty i/o shows up
and why there is a testsuite to check for that.

Does the debuggee know about the debugger, or is the pty i/o just stdout/stderr?

This doesn't seem stable in the face of multiple threads of execution in
the debuggee (or grandchild processes); IOW, pty slave writes from the
debuggee may continue from other non-TRACEME threads. Presumably that i/o
isn't being read either.

> (FWIW: I do think it's a better QoI factor if something returns data from
> a tube if we can know via side channels (break points) that something must
> have been written locally to the other end of the tube, if that can be
> ensured without too much other work)

Well, if the debugger simply continues to monitor the pty master, the i/o
will arrive.

I think it would be a shame if ptrace() usage forced a whole class of
i/o to be synchronous.

Regards,
Peter Hurley