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
Forum Updated to NodeBB v4.3 + New Features

Possible memory leak in QNetworkAccessManager

Scheduled Pinned Locked Moved General and Desktop
5 Posts 2 Posters 2.5k 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