Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Possible memory leak in QNetworkAccessManager

Possible memory leak in QNetworkAccessManager

Scheduled Pinned Locked Moved General and Desktop
5 Posts 2 Posters 2.6k Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • G Offline
    G Offline
    giorgio.cardarelli
    wrote on last edited by
    #1

    Hi, I'm running this simple code in valgrind and it finds some memory leaks. Where am I wrong? I'm using Qt5.0.2 shipped with Ubuntu Linux 13.04 64bit

    As you can see, I do delete the reply using deleteLater and qApp is quit with a proper delay, just to be completely sure that everything went as expected.

    Valgrind output is:
    @
    valgrind --leak-check=yes ./TestNetworkBug
    ...
    ==31550== LEAK SUMMARY:
    ==31550== definitely lost: 1,904 bytes in 26 blocks
    ==31550== indirectly lost: 2,601 bytes in 22 blocks
    ==31550== possibly lost: 0 bytes in 0 blocks
    ==31550== still reachable: 25,100 bytes in 605 blocks
    ==31550== suppressed: 0 bytes in 0 blocks
    @

    Thanks in advance,
    Giorgio

    @main.cpp
    #include <QCoreApplication>
    #include <QTimer>
    #include <QObject>

    #include "tester.h"

    int main(int argc, char *argv[])
    {
    QCoreApplication a(argc, argv);

    Tester tester(&a);
    
    QObject::connect(&tester, SIGNAL(readyToQuit()), &a, SLOT(quit()));
    QTimer::singleShot(1000, &tester, SLOT(get()));
    
    return a.exec&#40;&#41;;
    

    }@

    @Tester.h
    #ifndef TESTER_H
    #define TESTER_H

    #include <QObject>

    class QNetworkAccessManager;
    class QNetworkReply;

    class Tester : public QObject
    {
    Q_OBJECT
    public:
    explicit Tester(QObject *parent = 0);
    virtual ~Tester();

    signals:
    void readyToQuit();

    public slots:
    void get();
    void finished(QNetworkReply *reply);

    private:
    QNetworkAccessManager * manager;
    };

    #endif // TESTER_H
    @

    @Tester.cpp
    #include <QNetworkAccessManager>
    #include <QNetworkReply>
    #include <QtDebug>
    #include <QTimer>

    #include "tester.h"

    Tester::Tester(QObject parent) :
    QObject(parent)
    {
    manager = new QNetworkAccessManager(this);
    connect(manager, SIGNAL(finished(QNetworkReply
    )), this, SLOT(finished(QNetworkReply*)));
    }

    Tester::~Tester()
    {
    qDebug() << "~Tester";
    delete manager;
    }

    void Tester::get()
    {
    qDebug() << "Posting request";
    manager->get( QNetworkRequest( QUrl(QString("http://www.google.it"))) );
    }

    void Tester::finished(QNetworkReply *reply)
    {
    qDebug() << "Getting reply";
    reply->deleteLater();

    QTimer::singleShot(1000, this, SIGNAL(readyToQuit()));
    

    }
    @

    1 Reply Last reply
    0
    • sierdzioS Offline
      sierdzioS Offline
      sierdzio
      Moderators
      wrote on last edited by
      #2

      Valgrind is known to produce false positives for some Qt classes.

      I'm not sure setting the application as the parent for your Tester object is a good idea.

      Anyway, please try with newer Qt version.

      (Z(:^

      1 Reply Last reply
      0
      • G Offline
        G Offline
        giorgio.cardarelli
        wrote on last edited by
        #3

        Hi,

        same with Qt 5.2.1

        @
        ==312== LEAK SUMMARY:
        ==312== definitely lost: 1,640 bytes in 24 blocks
        ==312== indirectly lost: 4,191 bytes in 41 blocks
        ==312== possibly lost: 0 bytes in 0 blocks
        ==312== still reachable: 26,700 bytes in 608 blocks
        ==312== suppressed: 0 bytes in 0 blocks
        @

        On a side note: why shouldn't be a good idea to set qApp as the parent for a object? In this particular case, it makes no difference to set or not to set a parent for my Tester instance. But, in this case:

        @
        Tester * tester = new Tester(&a);
        @

        the idea is to let qApp call tester's destructor.

        Isn't it correct?

        1 Reply Last reply
        0
        • sierdzioS Offline
          sierdzioS Offline
          sierdzio
          Moderators
          wrote on last edited by
          #4

          In your case, you are creating the Tester object on a stack. So I guessed it will be first deleted by QApplication (after quit() is called), and then the standard out-of-scope deletion will be attempted. So it might be that this is what Valgrind reports as a leak here.

          Since you say that it makes no difference, I guess I was wrong.

          (Z(:^

          1 Reply Last reply
          0
          • G Offline
            G Offline
            giorgio.cardarelli
            wrote on last edited by
            #5

            I think your guess is more than correct, but in real life it actually makes no difference.

            On a side note, I would have expected a "double free or corruption" error, with a core-dump. But maybe I'm quite going off-topic here...

            1 Reply Last reply
            0

            • Login

            • Login or register to search.
            • First post
              Last post
            0
            • Categories
            • Recent
            • Tags
            • Popular
            • Users
            • Groups
            • Search
            • Get Qt Extensions
            • Unsolved