Question

I’m dealing with what I suspect to be a stack corruption bug in a program that occurs during the use of QNetworkAccessManager. Full source code is available here.

Judging from log output, I’m guessing that the bug is triggered after the asynchronous request on line 44 in calendar.cpp. I don’t have solid evidence of this; I’ve only noticed that the message on line 45 is the last log message most of the time.

Here are lines 39-46:

void Calendar::update()
{
    // Start calendar download asynchronously. After retrieving the
    // file, parseNetworkResponse will take over.
    Logger::instance()->add(CLASSNAME, "Fetching update for 0x" + QString::number((unsigned)this, 16) + "...");
    _naMgr.get(QNetworkRequest(_url));
    Logger::instance()->add(CLASSNAME, "Update request for 0x" + QString::number((unsigned)this, 16) + " was filed.");
}

This HTTP GET request is handled by the Calendar::parseNetworkResponse slot, which is connected to _naMgr‘s finished signal. Here are lines 170-174:

void Calendar::parseNetworkResponse(QNetworkReply* reply) {
    // TODO: we suspect that sometimes a SIGSEGV occurs within the bounds
    // of this function. We'll remove the excessive log calls when we've
    // successfully tracked down the problem.
    Logger::instance()->add(CLASSNAME, "Got update response for 0x" + QString::number((unsigned)this, 16) + ".");

Even when the log message on line 45 isn’t the last to appear in the log after a crash, there is always an update request in the log that is never followed up by the log message at line 174. This leads me to believe that an HTTP GET request might be ruining things here. The URLs for which GET requests are filed appear to be correct.

One of the reasons why I think there’s memory corruption involved is that the bug doesn’t consistently pop up even though the list of input calendars and the status of my internet connection remain the same. (I can trigger the bug with a minimum of 2 calendars.) Furthermore I saw this GCC output when I tried to learn more about the point of failure. I would have collected output from valgrind‘s memory checker to collect additional info but I don’t have a working Linux installation nearby at the moment.

Can this bug be related to incorrect use of Qt’s network libraries from my side? Have you got any other theories as to what might be causing the issue? This is my first time dealing with possible stack corruption and since I’m doing this solo hobby project in my spare time I don’t have anyone to train me in dealing with these issues.

Answer 1

In your finished slot, when you are processing the response set a global flag (bool) to “processing”

That way, if you get another response, you can either queue it up, or you can ignore it. The problem is probably more due to the fact that QNetworkAccessManager forks a thread to do its processing somewhere behind the scenes, which causes your code to perform access violations.

If you want I will jump on your project and have a closer look 🙂

~ Dan

My class for sending and receiving:

.h file

class sendRec : public QObject
{
    Q_OBJECT
public:
    sendRec(QObject *parent = 0);
    sendRec(QUrl);
    QString lastError;
    QUrl thisURL;
    //QNetworkAccessManager manager;
    //FUNCTIONS
    void doGet();
    void doPost(QByteArray*);
    void doPut(QString, QString);
    void doConnects(QNetworkReply *reply, QNetworkAccessManager *manager);

signals:
    void sendResponse(bool, QString*);
public slots:

    /** NETWORK_ACCESS_MANAGER_SLOT **/
    //SUCCESS SLOTS FOR BOTH
    void requestReturned(QNetworkReply * reply );
    //FAILURE SLOTS
    void proxyAuthFail(const QNetworkProxy & proxy, QAuthenticator * authenticator);
    void sslErrorFail(QNetworkReply * reply, const QList<QSslError> & errors);
    /** QNETWORK_REPLY_SLOTS **/
    //FAILURE SLOTS
    void reqError ( QNetworkReply::NetworkError code );
    void sslError ( const QList<QSslError> & errors );

};

.cpp:

#include "sendrec.h"

sendRec::sendRec(QObject *parent) :
    QObject(parent)
{
}


sendRec::sendRec(QUrl url) {
    thisURL = url;
}

void sendRec::doGet() {
    QNetworkRequest request(thisURL);
    QNetworkAccessManager *manager = new QNetworkAccessManager(this);
    QNetworkReply *reply = manager->get(request);
    doConnects(reply, manager);
}

void sendRec::doPost(QByteArray *message) {
    QNetworkRequest request(thisURL);
    QNetworkAccessManager *manager = new QNetworkAccessManager(this);
    QNetworkReply *reply = manager->post(request, *message);
    doConnects(reply, manager);
}

void sendRec::doConnects(QNetworkReply *reply, QNetworkAccessManager* manager){
    //Reply Connects
    QObject::connect(reply, SIGNAL(error(QNetworkReply::NetworkError)),
                     this, SLOT(reqError(QNetworkReply::NetworkError)));
    QObject::connect(reply, SIGNAL(sslErrors(QList<QSslError>)),
                     this, SLOT(sslError(QList<QSslError>)));
    //manager connects
    QObject::connect(manager, SIGNAL(finished(QNetworkReply*)),
               this, SLOT(requestReturned(QNetworkReply*)));
    QObject::connect(manager, SIGNAL(sslErrors(QNetworkReply*,QList<QSslError>)),
            this, SLOT(sslErrorFail(QNetworkReply*,QList<QSslError>)));
    QObject::connect(manager, SIGNAL(proxyAuthenticationRequired(QNetworkProxy,QAuthenticator*)),
               this, SLOT(proxyAuthFail(QNetworkProxy,QAuthenticator*)));


}


void sendRec::requestReturned(QNetworkReply * rep ){
    qDebug() << "Request Returned";
    QVariant status = rep->attribute(QNetworkRequest::HttpStatusCodeAttribute);
    if(status != 200 || status == NULL) {
        QString *lastError = new QString("ERROR: " + status.toString()
                                         + " " + rep->readAll());
        emit sendResponse(false, lastError);
    } else {
        QString *retString = new QString(rep->readAll());
        *retString = retString->trimmed();
        emit sendResponse(true, retString);
    }
    rep->manager()->deleteResource(rep->request());
    rep->manager()->deleteLater();
    rep->deleteLater();
    sender()->deleteLater();


}