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

WASM network code bugs

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P1: Critical
    • Resolution: Done
    • Affects Version/s: 5.15.0
    • Fix Version/s: 5.15.1
    • Component/s: Network
    • Labels:
      None
    • Platform/s:
      WebAssembly
    • Commits:
      36c80ec4076fcbc44c8c27de5c3b11398be39152 b483c65adc47918c697258389dc3b2a95336a90e (qt/tqtc-qtbase/5.15.1)

      Description

      The WASM networking code crashes on us. Especially in more complex setups (5.14 also did not work without modifications from my side):

      QNetworkReplyWasmImplPrivate::doSendRequest()
      does not correctly handle headers.

          if (headersData.count() > 0) {
              const char* customHeaders[arrayLength];
              int i = 0;
              for (i; i < headersData.count() * 2; (i = i + 2)) {
                  customHeaders[i] = headersData[i].constData();
                  customHeaders[i + 1] = request.rawHeader(headersData[i]).constData();
              }
              customHeaders[i] = nullptr;
              attr.requestHeaders = customHeaders;
          }
      

      This code cannot work as headerData is accessed with i which can go twice as high as headerData.count()

      I'm also not sure whether its save to define customHeaders like this, especially not in the context of emscripten, but I assume the headers need to be allocated somehow.

          if (outgoingData) { // data from post request
              // handle extra data
              QByteArray extraData;
              extraData = outgoingData->readAll(); // is there a size restriction here?
              if (!extraData.isEmpty()) {
                  attr.requestData = extraData.constData();
                  attr.requestDataSize = extraData.size();
              }
          }
      

      This code also looks dangerous and unlikely to reliably work. extraData is going out of scope, I'm not sure the constData pointer object will survive that, but it non-WASM environments this is very likely to crash.

          m_fetch = emscripten_fetch(&attr, request.url().toString().toUtf8());
      

      Same here. Its not clear whether emscripten_fetch copies the provided url. If not this is likely to crash.

      I would provide a fix, but currently we have a lot of remaining issues which are not fixed, by the above changes (except for a simple test case).

        Attachments

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

          Activity

            People

            Assignee:
            lpotter Lorn Potter
            Reporter:
            alexj Alexander Jährling
            Votes:
            2 Vote for this issue
            Watchers:
            5 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:

                Gerrit Reviews

                There are no open Gerrit changes