Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-16123

Full read buffer triggers infinite busy loop in QAbstractSocket

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • P2: Important
    • 4.8.0
    • 4.6.3, 4.7.1
    • Network: Sockets
    • None
    • 8d4cd52b6981a4e6deea7fdb77f56e40c4f3e6ba

    Description

      Following the mailing list post here: http://lists.trolltech.com/pipermail/qt-interest/2010-December/029781.html

      While using KDE I discovered that downloading from a high-bandwith server can cause the kio_http process to stop responding while using 100% CPU. I tracked the problem down to a 'forever' loop in qabstractsocket.cpp. The offending lines are in QAbstractSocket::waitForReadyRead. In Qt 4.6.3 and 4.7.1 the loop is at lines 1832--1859 and (last I checked) in master the lines begin at 1862.

      In that loop are the lines:

      if (readyToRead) {
           if (d->canReadNotification())
               return true;
       }
      

      The call to canReadNotification() returns false if the read buffer has no spare space, so the busy loop will not exit at the following line like it normally would. Assuming the socket remains connected, the loop does not terminate at all. (This also means that the calling program will be unable to flush the buffer.)

      While the caller should not request Qt to add to a full buffer (I will file a bug with KDE about this, once I can narrow down the cause), Qt should not enter an infinite busy loop because of it, but instead return with some kind of error.

      Attachments

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

          People

            xcm Martin Petersson (Inactive)
            blhiggins Brendon Higgins
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Gerrit Reviews

                There are no open Gerrit changes