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

[Chris Purvis]

Peter,

So is calling tcflush() a solution here?

Regards,
Chris
-- 
Chris Purvis
Senior Development Manager 

Micro Focus

chris.purvis@xxxxxxxxxxxxxx
The Lawn, 22-30 Old Bath Road
Newbury, Berkshire, RG14 1QN, UK
Direct:    +44 1635 565282


-----Original Message-----
From: Peter Hurley [mailto:peter@xxxxxxxxxxxxxxxxxx] 
Sent: 05 May 2015 14:29
To: Nic Percival; Michael Matz; Kevin Fletcher; Paul Matthews; Chris Purvis
Cc: NeilBrown; Greg Kroah-Hartman; Jiri Slaby; linux-kernel@xxxxxxxxxxxxxxx
Subject: Re: [PATCH bisected regression] input_available_p() sometimes says 'no' when it should say 'yes'

Stop top-posting.

On 05/05/2015 08:03 AM, Nic Percival wrote:
> 
> There is only ever one debuggee process.
> My original demo (and indeed the original test failure) is not threaded. The debugger is multi-threaded.
> 
> I've brought in Chris, Fletch and Paul, my immediate colleagues, into the discussion.
> 
> The email thread is getting a little tangled, however, from my standpoint I have..
> 
> 1) poll tells us we have nothing to read on a pty, when we know something was written into the other end.

You're using a synchronization mechanism (ptrace) to validate an
asynchronous process (tty i/o). That's not going to work.

> 2) Given that 'poll' is not telling us that data has been written into the pty, what can we use? Surely that is what poll is for.

poll() doesn't tell you that nothing has been written.

You're inferring that using a broken understanding of terminal i/o:
ttys are not synchronous pipes.

> 3) If a debuggee program has displayed 'how old are you?' and then hit a breakpoint on the 'ACCEPT' response, then the question might very well not be displayed, despite the debugger  sitting on the statement some way subsequent to the display. 

Let's extend your logic process here to a general-purpose debugger
that can control all output devices.

1. The debugger and debuggee are running on X-Windows.
2. The debuggee outputs 'how old are you?'
3. The debugger immediately halts the debuggee and all output devices.

The output will not appear on the monitor because X-Windows
output is asynchronous. So is terminal i/o.

 
> 4) If I understand correctly, the modification is a performance enhancement. Obviously in the case of 'ptrace' debugging, performance is not a requirement.

Nothing obvious about it. Not all uses of ptrace are interactive, and certainly don't
want alternate behavior based on whether the process is ptraced.

> 5) Given 'xterm' use pty's, could a scenario happen where a user is prompted 'How old are you?' in the xterm, but an input (getchar, whatever) is hit before that output is displayed? With or without ptrace?

Of course. It's called typeahead. Since tty i/o is buffered, the following is possible:

1. The user types '15\r'
2. The process writes 'How old are you?'
3. The process reads '15\n'

Processes that don't want typeahead call tcflush() before reading input.

Regards,
Peter Hurley

> Thanks,
> Nic
> 
> 
> 
> -----Original Message-----
> From: Peter Hurley [mailto:peter@xxxxxxxxxxxxxxxxxx] 
> Sent: 05 May 2015 12:19
> To: Nic Percival; Michael Matz
> Cc: NeilBrown; Greg Kroah-Hartman; Jiri Slaby; linux-kernel@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH bisected regression] input_available_p() sometimes says 'no' when it should say 'yes'
> 
> 
> A: No.
> Q: Should I include quotations after my reply?
> 
> http://daringfireball.net/2007/07/on_top
> 
> 
> On 05/05/2015 04:20 AM, Nic Percival wrote:
>> Michael is correct.
>> Our COBOL debugger has a test feature whereby we can drive it to step through debugging code, hitting breakpoints and so on.
>> The debugger maintains a 'user screen' which is what the 'debuggee' process has displayed.
>> This is communicated to the debugger with pseudo-tty's.
>> The state of this user screen is checked as part of this (and other) tests.
> 
> So the debugger doesn't display output from other non-TRACEME threads or child processes of the debuggee, right?
> 
> When that's fixed, you'll see that the "test failure" has gone away.
> 
>> The actual test failure is a failure of some text to be displayed on the debuggee user screen when we know, given it has hit a certain breakpoint, that the text has been written.
>>
>> What is worse is its non-deterministic.
> 
> That your test is non-deterministic stems from the fact that the i/o is asynchronous.
> 
> You would experience the same problem if your test setup was a tty in loopback.
> 
>> Sometimes the text makes it and is displayed, so it wouldn't even be practical to modify the test to make it pass.
>> We wouldn't really want to do that anyway - the test is just fine on other earlier SUSE, on RedHat (intel and 390), HP/UX, AIX and Solaris.
> 
> There is a reason Linux is the platform of choice for scalability.
> 
> Regards,
> Peter Hurley
> 
>> -----Original Message-----
>> From: Michael Matz [mailto:matz@xxxxxxx]
>> Sent: 04 May 2015 13:24
>> To: Peter Hurley
>> Cc: NeilBrown; Nic Percival; Greg Kroah-Hartman; Jiri Slaby; 
>> linux-kernel@xxxxxxxxxxxxxxx
>> Subject: Re: [PATCH bisected regression] input_available_p() sometimes says 'no' when it should say 'yes'
>>
>> 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.
>>
>> (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)
>>
>>
>> Ciao,
>> Michael.
>>
>>
>> This message has been scanned for malware by Websense. 
>> www.websense.com
>>
>