D4975: Prevent misdetection of EOF on Linux

[Peter Wu]

Lekensteyn created this revision.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: Frameworks.

REVISION SUMMARY
  On Linux, even if slave activity is detected on a master fd, FIONREAD
  can still return zero available bytes in the buffer. Previously this
  would prevent further signals from being emitted even if new IO arrived
  (since the readNotifier is disabled) which in its turn prevented the
  Konsole output from being updated.
  
  A race condition in the kernel is suspected, the first known broken
  kernel is v4.1.10-89-g5eb491ba5d06.
  
  BUG: 372991

TEST PLAN
  Tested in conjunction with konsole v16.12.1-60-g151215a9 with this debug patch applied:
  
    diff --git a/src/kptydevice.cpp b/src/kptydevice.cpp
    index 92b443b..4dfcd02 100644
    --- a/src/kptydevice.cpp
    +++ b/src/kptydevice.cpp
    @@ -273,6 +273,7 @@ struct KPtyDevicePrivate : public KPtyPrivate {
         KRingBuffer writeBuffer;
     };
     
    +#include <cstdio>
     bool KPtyDevicePrivate::_k_canRead()
     {
         Q_Q(KPtyDevice);
    @@ -310,6 +311,9 @@ bool KPtyDevicePrivate::_k_canRead()
             // select() will trigger again anyway if an EOF condition was found, and
             // only then we will accept it.
             if (!available && !maybeEof) {
    +            FILE *fp = fopen("/tmp/EOF", "a");
    +            fprintf(fp, "Maybe EOF!?\n");
    +            fclose(fp);
                 maybeEof = true;
                 return true;
             } else if (available) {
  
  Indeed, the /tmp/EOF file is being written and the Konsole output no longer "hangs".
  
  Closing a tab (via EOF in bash or closing the tab) somehow does not trigger this debug print, perhaps the watcher is disabled elsewhere. (This is an observation and not a problem.)

REPOSITORY
  R291 KPty

REVISION DETAIL
  https://phabricator.kde.org/D4975

AFFECTED FILES
  src/kptydevice.cpp

To: Lekensteyn, hindenburg, #konsole
Cc: #frameworks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20170308/21171581/attachment.html>