Crash when QNetworkReply is aborted due to timeout

[TangJayce]

I'm in China and can't access YouTube without a VPN.
There is a crash problem here.
The call to setTransferTimeout() is bound to crash if it doesn't reply with data within the time set by the parameter.

void MainWindow::on_pushButton_clicked()
{
    fetchData(QString("https://www.youtube.com/"))
    .then([](const QByteArray &bytes) {
        qDebug().noquote() << "fetch data success:" << bytes;
    }, [](const std::exception& e) {
        qDebug() << "fetch data error:" << e.what();
    });
}

QCoro::Task<QByteArray> MainWindow::fetchData(const QUrl &url)
{
    qDebug() << "request:" << url.toString();
    QNetworkRequest request(url);
    // request.setTransferTimeout(10000);
    QNetworkAccessManager manager;
    const auto reply = co_await manager.get(request);
    if (reply->error() != QNetworkReply::NoError) {
        qDebug() << "request error" << reply->errorString();
        co_return {};
    }
    co_return reply->readAll();
}

running environment: Qt_5_15_2_MSVC2019_32bit-Debug

[danvratil]

Setting a timeout on QNetworkRequest and actually hiting the timeout aborts the QNetworkReply, which most likely results in some shenanigans inside QCoroNetworkReply. Should be easy to write a reproducer unit-test for this

[danvratil]

Hmm, I added this unit-test:

QCoro::Task<> testRequestTimeout_coro(QCoro::TestContext) {
        auto request = buildRequest(QStringLiteral("block"));
        request.setTransferTimeout(10);
        QNetworkAccessManager nam;
        auto reply = co_await nam.get(request);
        QCORO_VERIFY(reply != nullptr);
        QCORO_VERIFY(reply->isFinished());
        QCORO_COMPARE(reply->error(), QNetworkReply::OperationCanceledError);
}

...and it doesn't crash (buildRequest("block") just creates a QNetworkRequest to an endpoint on an internal testing HTTP server that will reply after 5 seconds)

Any chance you could try to get some kind of stacktrace?

[TangJayce]

C:\Users\qt\work\qt\qtbase\src\corelib\kernel\qobject.cpp:3770: error: Debugger encountered an exception: Exception at 0x7b066f0b, code: 0xc0000005: read access violation at: 0xfeeefefe, flags=0x0 (first chance)

[danvratil]

Thanks a lot, I understand the problem now :) It does not crash on Linux, and not even ASAN detects the problem, but running the testcase under valgrind reveals the same underlying problem with accessing memory that has been already free'd.

The problem is kinda simple: when the request is internally aborted in QNetworkReplyHttpImpl, the finished() signal is emitted synchronously - this signal synchronously wakes up your fetchData() coroutine, which handles the error and returns. At this point the QNetworkAccessManager and all other associated state (including the QNetworkReplyHttpImpl) is destroyed. As the coroutine has finished, the execution returns back into QNetworkReplyHttpIml as-if it just returned from the finished() signal, and it attempts to continue to run it. However, at this point, the entire QNetworkReplyHttpImpl has already been free'd alongside the QNetworkAccessManager, so the this pointer is invalid and it crashes at some point later.

Technically, this crash can be reproduced without coroutines, all you need to do is to delete the QNetworkAccessManager in your slot that handles the QNetworkReply::finished() signal.

Until we fix this in QCoro, you can workaround this in your code either by using a global QNetworkAccessManager that outlives your coroutines, or allocate it on heap and delete it with deleteLater().

In QCoro, the fix should be as simple as not using direct connection, but queued connection to handle signals from QNetworkReply. While there's a small performance hit, it will solve this problem easilly.

[danvratil]

Just a small addendum that I realized while making the commit: the reason why ASAN does not detect the invalid memory access is that the memory issue occurs inside Qt and I don't have Qt built with ASAN, only QCoro.