memory leak - where?

Printable View

Show 50 post(s) from this thread on one page

Re: memory leak - where?

Report like this?
Code:

==29102== 3,392 bytes in 143 blocks are possibly lost in loss record 371 of 380 ==29102== at 0x4023C4C: malloc (vg_replace_malloc.c:195) ==29102== by 0x50146F3: ??? (in /usr/lib/libfontconfig.so.1.4.4) ==29102== by 0x5019579: ??? (in /usr/lib/libfontconfig.so.1.4.4) ==29102== by 0x501A982: ??? (in /usr/lib/libfontconfig.so.1.4.4) ==29102== by 0x5368A54: ??? (in /usr/lib/libexpat.so.1.5.2) ==29102== by 0x53698A0: ??? (in /usr/lib/libexpat.so.1.5.2) ==29102== by 0x536ADB0: ??? (in /usr/lib/libexpat.so.1.5.2) ==29102== by 0x536B969: ??? (in /usr/lib/libexpat.so.1.5.2) ==29102== by 0x536264B: XML_ParseBuffer (in /usr/lib/libexpat.so.1.5.2) ==29102== by 0x50187FA: FcConfigParseAndLoad (in /usr/lib/libfontconfig.so.1.4.4) ==29102== by 0x5018B43: FcConfigParseAndLoad (in /usr/lib/libfontconfig.so.1.4.4) ==29102== by 0x501A038: ??? (in /usr/lib/libfontconfig.so.1.4.4)
It's from application where nothing happens - there's only window.

Sorry I'm very stubborn about this memory leak but I've wrote some applications and all of them works fine on PC but on ARM after some time applications starting to work very slow and it looks like everything freezes (especially applications which uses SQLite databases). I suppose It's memory leak (applications are not complicated). Maybe I should look for cause somewhere else?

thanks in advance
best regards
Tomasz

1st September 2010, 23:27
SixDegrees

Re: memory leak - where?

Wait - you suppose it's a memory leak? You're not sure? Why do you think it's a memory leak?

You aren't going to find solutions to your problems unless you describe them correctly. Use a tool like 'top' to monitor your application's memory usage over time, and see if it increases indefinitely. Or if there's some runaway CPU process bogging down the system. Or try netstat if you're connecting to a remote server, to see if there's some aberrant network activity that might be causing the slowdown.

Or, if you're really fixated on believing it's a memory issue, why not simply try destroying the connection you started off suspecting, and see if that makes the problem go away?

Or you can continue to pore over the valgrind output, looking for bytes marked as definitely lost; as you can see, it provides references back to the line in your source code where the problem originated.
2nd September 2010, 11:22
Tomasz

Re: memory leak - where?

Quote:

Originally Posted by SixDegrees

Use a tool like 'top' to monitor your application's memory usage over time, and see if it increases indefinitely.

I've used 'top' and memory increases all the time the program works. Maybe someone could check my project (it's really short) because I have no idea what I'm doing wrong. I will be really grateful I can only guess it can by connected with databases...

thanks in advance
best regards
Tomasz
2nd September 2010, 12:36
wysota

Re: memory leak - where?

Does valgrind report leaks in your code?
2nd September 2010, 13:00
Tomasz

Re: memory leak - where?

Yes It reports memory leaks as I said earlier. He reports it's connected with database functions (I'm still learning to use valgrind so I can't say nothing more now) but I know it happens mostly when I'm using functions that are doing something with database... so it would be nice if someone check my whole code because I think I'm doing the same mistake in every app...

thanks in advance
best regards
Tomasz
2nd September 2010, 13:30
wysota

Re: memory leak - where?

Quote:

Originally Posted by Tomasz

Yes It reports memory leaks as I said earlier. He reports it's connected with database functions (I'm still learning to use valgrind so I can't say nothing more now) but I know it happens mostly when I'm using functions that are doing something with database... so it would be nice if someone check my whole code because I think I'm doing the same mistake in every app...

Please show us the relevant sections of the report and corresponding lines of your source code.

Re: memory leak - where?

Using valgrind for QT is very difficult. It report about 84000 errors (like "Conditional jump or move depends on uninitialised value(s)"). I really don't know what is important here. I was observing my program and I've noticed that memory is growing while I'm using function in code below.

Code:

bool MainWindow::pobierzKomunikaty()
{
    bool ok;
    QTextStream out(stdout);
    QString zapytanie;
    QSqlRecord rec;
    QSqlQueryModel queryModel;
    QSqlQuery query;
    QFont font;
 
    font.setPointSize(7);
 
    odczytanoOstatnieKomunikaty=0;
 
    ok = bdb.open();
 
    if (ok)
    {
        out << endl << "Otworzylem baze!" << endl ;
    } else {
        out << "Nie udalo sie otworzyc bazy!" << endl;
    }
 
    queryModel.clear();
 
    queryModel.setQuery("SELECT * FROM server_notifications WHERE complete='0'", bdb);
 
    liczbaWiadomosci = queryModel.rowCount();
 
    bdb.close();
 
#ifdef DEBUG
    out << "Mamy: " << liczbaWiadomosci << " wiadomosci!" << endl;
#endif
 
 
    for(int i=0 ; i<liczbaWiadomosci; i++)
    {
        rec = queryModel.record(i);
 
 
#ifdef DEBUG
        out << rec.value(1).toString() << ": ";
        out << rec.value(2).toString() << endl;
#endif
 
        QMessageBox *msgBox=new QMessageBox;
 
        if(rec.value(1).toString()=="warning") msgBox->setIcon(QMessageBox::Warning);
        else if (rec.value(1).toString()=="info") msgBox->setIcon(QMessageBox::Information);
        else if (rec.value(1).toString()=="error") msgBox->setIcon(QMessageBox::Critical);
 
        if(rec.value(1).toString()!="confirmation")
        {
                msgBox->setFont(font);
                msgBox->setWindowTitle(rec.value(1).toString());
                msgBox->setText(rec.value(2).toString());
 
                QSpacerItem* horizontalSpacer = new QSpacerItem(240, 290, QSizePolicy::Minimum, QSizePolicy::Minimum);
                QGridLayout* layout = (QGridLayout*)msgBox->layout();
                layout->addItem(horizontalSpacer, layout->rowCount(), 0, 1, layout->columnCount());
 
                msgBox->move(0,0);
                msgBox->exec();
 
                delete msgBox;
 
                ok = bdb.open();
 
                zapytanie.clear();
                zapytanie="update server_notifications set complete='1'";
                zapytanie.append(" where id='");
                zapytanie.append(QString::number(rec.value(0).toInt()));
                zapytanie.append("'");
 
                query.clear();
                query.prepare(zapytanie);
                ok = query.exec();
                query.clear();
 
                bdb.close();
            } else if (rec.value(1).toString()=="confirmation") {
                msgBox->setIcon(QMessageBox::Question);
                msgBox->setFont(font);
                msgBox->setWindowTitle(rec.value(1).toString());
                msgBox->setText(rec.value(2).toString());
                msgBox->setStandardButtons(QMessageBox::Yes | QMessageBox::No);
 
                QSpacerItem* horizontalSpacer = new QSpacerItem(240, 290, QSizePolicy::Minimum, QSizePolicy::Minimum);
                QGridLayout* layout = (QGridLayout*)msgBox->layout();
                layout->addItem(horizontalSpacer, layout->rowCount(), 0, 1, layout->columnCount());
 
                msgBox->move(0,0);
                int result = msgBox->exec();
 
                delete msgBox;
 
                ok = bdb.open();
 
                zapytanie.clear();
                if (result == QMessageBox::Yes) zapytanie="update server_notifications set complete='2'";
                else if (result == QMessageBox::No) zapytanie="update server_notifications set complete='3'";
                zapytanie.append(" where id='");
                zapytanie.append(QString::number(rec.value(0).toInt()));
                zapytanie.append("'");
 
                query.clear();
                query.prepare(zapytanie);
                ok = query.exec();
                query.clear();
 
                bdb.close();
            }
    }
 
    zapytanie.clear();
    rec.clear();
    queryModel.clear();
    odczytanoOstatnieKomunikaty=1;
 
    return ok;
}
 
bool MainWindow::wyswietlKomunikaty()
{
    if(odczytanoOstatnieKomunikaty==0)
    {
 
    } else
    {
        pobierzKomunikaty();
        odczytajNotificationInterval();
        timer.start(notificationInterval);
    }
 
    return 1;
}
 
bool MainWindow::odczytajNotificationInterval()
{
    bool ok;
    QTextStream out(stdout);
    QSqlRecord rec;
    QSqlQueryModel queryModel;
 
    ok = bdb.open();
 
 
    if (ok)
    {
        out << endl << "Otworzylem baze!" << endl ;
    } else {
        out << "Nie udalo sie otworzyc bazy!" << endl;
    }
 
    queryModel.clear();
 
    queryModel.setQuery("SELECT * FROM config WHERE name='qt-notification-interval'", bdb);
 
    rec = queryModel.record(0);
    notificationInterval = (rec.value(1).toInt())*1000;
 
#ifdef DEBUG
    out << "Notification interval: " << notificationInterval << " ms" << endl;
#endif
 
    rec.clear();
    queryModel.clear();
    bdb.close();
 
    return ok;
}

And really I can't say nothing more. Like I said valgrind generates thousands of messages for QT applications. Problem is important because when program runs on ARM it takes minute after minute more memory resources.

thanks in advance
best regards
Tomasz

3rd September 2010, 07:34
wysota

Re: memory leak - where?
Here is an example app:
Code:

#include <QtGui> int main(int argc, char **argv){ QApplication app(argc, argv); QLineEdit *le = new QLineEdit; QString *str = new QString("xxx"); le->setText(*str); le->show(); return app.exec(); }
And valgrind report for it (the parts that are relevant):

Quote:

==12196== HEAP SUMMARY:
==12196== in use at exit: 195,287 bytes in 2,848 blocks
==12196== total heap usage: 72,096 allocs, 69,248 frees, 10,244,645 bytes allocated
==12196==
==12196== 4 bytes in 1 blocks are definitely lost in loss record 27 of 566
==12196== at 0x40244F0: operator new(unsigned int) (vg_replace_malloc.c:214)
==12196== by 0x8048811: main (main.cpp:7)
==12196==
==12196== 16,548 (20 direct, 16,528 indirect) bytes in 1 blocks are definitely lost in loss record 566 of 566
==12196== at 0x40244F0: operator new(unsigned int) (vg_replace_malloc.c:214)
==12196== by 0x80487ED: main (main.cpp:6)
==12196==
==12196== LEAK SUMMARY:
==12196== definitely lost: 1,401 bytes in 19 blocks
==12196== indirectly lost: 16,548 bytes in 113 blocks
==12196== possibly lost: 60,653 bytes in 611 blocks
==12196== still reachable: 116,685 bytes in 2,105 blocks
==12196== suppressed: 0 bytes in 0 blocks
==12196== Reachable blocks (those to which a pointer was found) are not shown.
==12196== To see them, rerun with: --leak-check=full --show-reachable=yes
==12196==
==12196== For counts of detected and suppressed errors, rerun with: -v
==12196== ERROR SUMMARY: 135 errors from 135 contexts (suppressed: 123 from 9)

You can see it immediately says where to look for problems. The rest of the reports in my case are either false positives or caused by Qt's dependencies (like KDE or fontconfig).

Re: memory leak - where?

I've checked program with valgrind. It produced hundreds of messages.

It' starts with:

Code:

==27551== HEAP SUMMARY:
==27551==     in use at exit: 6,339,826 bytes in 16,037 blocks
==27551==   total heap usage: 239,607 allocs, 223,570 frees, 63,095,584 bytes allocated
==27551== 
==27551== 2 bytes in 1 blocks are possibly lost in loss record 5 of 3,561
==27551==    at 0x4023C4C: malloc (vg_replace_malloc.c:195)
==27551==    by 0x50F2ED3: g_malloc (in /lib/libglib-2.0.so.0.2400.1)
==27551==    by 0x510B768: g_strdup (in /lib/libglib-2.0.so.0.2400.1)
==27551==    by 0x5121060: g_get_language_names (in /lib/libglib-2.0.so.0.2400.1)
==27551==    by 0x51153F9: g_thread_init_glib (in /lib/libglib-2.0.so.0.2400.1)
==27551==    by 0x50A360D: g_thread_init (in /usr/lib/libgthread-2.0.so.0.2400.1)
==27551==    by 0x4CFEAF0: QEventDispatcherGlibPrivate::QEventDispatcherGlibPrivate(_GMainContext*) (qeventdispatcher_glib.cpp:297)
==27551==    by 0x427F4CF: QGuiEventDispatcherGlibPrivate::QGuiEventDispatcherGlibPrivate() (qguieventdispatcher_glib.cpp:171)
==27551==    by 0x427F5C2: QGuiEventDispatcherGlib::QGuiEventDispatcherGlib(QObject*) (qguieventdispatcher_glib.cpp:186)
==27551==    by 0x4246454: QApplicationPrivate::createEventDispatcher() (qapplication_x11.cpp:606)
==27551==    by 0x4CD54B8: QCoreApplication::init() (qcoreapplication.cpp:555)
==27551==    by 0x4CD5726: QCoreApplication::QCoreApplication(QCoreApplicationPrivate&) (qcoreapplication.cpp:476)

There are a lot of messages like that above not connected directly with my code. Bu I've found a lot of like this:

Code:

[...]
 
==27551== 24 bytes in 1 blocks are possibly lost in loss record 1,088 of 3,561
==27551==    at 0x4023C4C: malloc (vg_replace_malloc.c:195)
==27551==    by 0x7EFE9CA: sqlite3MemMalloc (sqlite3.c:12607)
==27551==    by 0x7EC92CF: mallocWithAlarm (sqlite3.c:15910)
==27551==    by 0x7EC93C7: sqlite3Malloc (sqlite3.c:15938)
==27551==    by 0x7F1DF40: unixOpen (sqlite3.c:25494)
==27551==    by 0x7EC8CF8: sqlite3OsOpen (sqlite3.c:12229)
==27551==    by 0x7EEB2F3: sqlite3BtreeFactory (sqlite3.c:34537)
==27551==    by 0x7EF4839: openDatabase (sqlite3.c:96157)
==27551==    by 0x7EC6774: QSQLiteDriver::open(QString const&, QString const&, QString const&, QString const&, int, QString const&) (qsql_sqlite.cpp:533)
==27551==    by 0x4039760: QSqlDatabase::open() (qsqldatabase.cpp:842)
==27551==    by 0x804C91F: MainWindow::pobierzKomunikaty() (in /home/tomek/projekt/start-build-desktop/start) //important???
==27551==    by 0x804E224: MainWindow::MainWindow(QWidget*) (in /home/tomek/projekt/start-build-desktop/start)
 
[...]
 
==27551== 32 bytes in 1 blocks are possibly lost in loss record 1,480 of 3,561
==27551==    at 0x4023C4C: malloc (vg_replace_malloc.c:195)
==27551==    by 0x7EFE9CA: sqlite3MemMalloc (sqlite3.c:12607)
==27551==    by 0x7EC92CF: mallocWithAlarm (sqlite3.c:15910)
==27551==    by 0x7EC93C7: sqlite3Malloc (sqlite3.c:15938)
==27551==    by 0x7ED6F4B: sqlite3HashInsert (sqlite3.c:19830)
==27551==    by 0x7ED8CCC: sqlite3FindCollSeq (sqlite3.c:69693)
==27551==    by 0x7EF35DC: createCollation (sqlite3.c:95936)
==27551==    by 0x7EF4676: openDatabase (sqlite3.c:96137)
==27551==    by 0x7EC6774: QSQLiteDriver::open(QString const&, QString const&, QString const&, QString const&, int, QString const&) (qsql_sqlite.cpp:533)
==27551==    by 0x4039760: QSqlDatabase::open() (qsqldatabase.cpp:842)
==27551==    by 0x804C91F: MainWindow::pobierzKomunikaty() (in /home/tomek/projekt/start-build-desktop/start)
==27551==    by 0x804E224: MainWindow::MainWindow(QWidget*) (in /home/tomek/projekt/start-build-desktop/start)
==27551==
==27551== 32 bytes in 1 blocks are possibly lost in loss record 1,481 of 3,561
==27551==    at 0x4023C4C: malloc (vg_replace_malloc.c:195)
==27551==    by 0x7EFE9CA: sqlite3MemMalloc (sqlite3.c:12607)
==27551==    by 0x7EC92CF: mallocWithAlarm (sqlite3.c:15910)
==27551==    by 0x7EC93C7: sqlite3Malloc (sqlite3.c:15938)
==27551==    by 0x7ED6F4B: sqlite3HashInsert (sqlite3.c:19830)
==27551==    by 0x7ED8CCC: sqlite3FindCollSeq (sqlite3.c:69693)
==27551==    by 0x7EF35DC: createCollation (sqlite3.c:95936)
==27551==    by 0x7EF46FD: openDatabase (sqlite3.c:96143)
==27551==    by 0x7EC6774: QSQLiteDriver::open(QString const&, QString const&, QString const&, QString const&, int, QString const&) (qsql_sqlite.cpp:533)
==27551==    by 0x4039760: QSqlDatabase::open() (qsqldatabase.cpp:842)
==27551==    by 0x804C91F: MainWindow::pobierzKomunikaty() (in /home/tomek/projekt/start-build-desktop/start)
==27551==    by 0x804E224: MainWindow::MainWindow(QWidget*) (in /home/tomek/projekt/start-build-desktop/start)
 
[...]

And some like this:

Code:

==27551== 2,436 (256 direct, 2,180 indirect) bytes in 1 blocks are definitely lost in loss record 3,433 of 3,561
==27551==    at 0x4023D47: realloc (vg_replace_malloc.c:476)
==27551==    by 0x5270F56: ??? (in /usr/lib/libfontconfig.so.1.4.4)
==27551==    by 0x52719AC: ??? (in /usr/lib/libfontconfig.so.1.4.4)
==27551==    by 0x52720FB: ??? (in /usr/lib/libfontconfig.so.1.4.4)
==27551==    by 0x527231F: ??? (in /usr/lib/libfontconfig.so.1.4.4)
==27551==    by 0x5264A27: FcDefaultSubstitute (in /usr/lib/libfontconfig.so.1.4.4)
==27551==    by 0x444849A: loadFc(QFontPrivate const*, int, QFontDef const&) (qfontdatabase_x11.cpp:1545)
==27551==    by 0x444B8E5: QFontDatabase::load(QFontPrivate const*, int) (qfontdatabase_x11.cpp:1939)
==27551==    by 0x4423C29: QFontPrivate::engineForScript(int) const (qfont.cpp:270)
==27551==    by 0x443BD26: QFontMetricsF::leading() const (qfontmetrics.cpp:1190)
==27551==    by 0x4359653: qt_format_text(QFont const&, QRectF const&, int, QTextOption const*, QString const&, QRectF*, int, int*, int, QPainter*) (qpainter.cpp:7738)
==27551==    by 0x435A695: QPainter::drawText(QRect const&, int, QString const&, QRect*) (qpainter.cpp:5807)
 
[...]
 
==27551== 4,872 (512 direct, 4,360 indirect) bytes in 2 blocks are definitely lost in loss record 3,483 of 3,561
==27551==    at 0x4023D47: realloc (vg_replace_malloc.c:476)
==27551==    by 0x5270F56: ??? (in /usr/lib/libfontconfig.so.1.4.4)
==27551==    by 0x52719AC: ??? (in /usr/lib/libfontconfig.so.1.4.4)
==27551==    by 0x52720FB: ??? (in /usr/lib/libfontconfig.so.1.4.4)
==27551==    by 0x527231F: ??? (in /usr/lib/libfontconfig.so.1.4.4)
==27551==    by 0x5264A27: FcDefaultSubstitute (in /usr/lib/libfontconfig.so.1.4.4)
==27551==    by 0x444849A: loadFc(QFontPrivate const*, int, QFontDef const&) (qfontdatabase_x11.cpp:1545)
==27551==    by 0x444B8E5: QFontDatabase::load(QFontPrivate const*, int) (qfontdatabase_x11.cpp:1939)
==27551==    by 0x4423C29: QFontPrivate::engineForScript(int) const (qfont.cpp:270)
==27551==    by 0x445FC39: QScriptLine::setDefaultHeight(QTextEngine*) (qtextengine.cpp:2009)
==27551==    by 0x446F072: QTextLine::layout_helper(int) (qtextlayout.cpp:1756)
==27551==    by 0x4470F82: QTextLine::setLineWidth(double) (qtextlayout.cpp:1601)
 
[...]

And the final summary looks like this:

Code:

==27551== LEAK SUMMARY:
==27551==    definitely lost: 2,344 bytes in 11 blocks
==27551==    indirectly lost: 11,360 bytes in 568 blocks
==27551==    possibly lost: 4,787,191 bytes in 8,606 blocks
==27551==    still reachable: 1,538,931 bytes in 6,852 blocks
==27551==    suppressed: 0 bytes in 0 blocks

I haven't found any message connected directly with code. Functions mentioned in messages I've posted earlier.
Any idea?

thanks in advance
best regards
Tomasz

5th September 2010, 08:10
wysota

Re: memory leak - where?

These are most likely false positives as you probably don't close the database connection gracefully when you exit your application, but that's ok. It could also be that the application crashes and that's why QCoreApplication's destructor doesn't have a chance to run. The rest of the leaks are unrelated to Qt and you can't do anything about them (apart from not using the offending libraries, such as fontconfig).
5th September 2010, 14:08
Tomasz

Re: memory leak - where?

Quote:

Originally Posted by wysota

These are most likely false positives as you probably don't close the database connection gracefully when you exit your application, but that's ok. It could also be that the application crashes and that's why QCoreApplication's destructor doesn't have a chance to run. The rest of the leaks are unrelated to Qt and you can't do anything about them (apart from not using the offending libraries, such as fontconfig).

My application should work for a long time without problems, but more it's works valgrind shows more memory leaks. I'm always closing database after using it with MyDatabse.close(); Is there anything more I can do to make my application more reliable?

thanks in advance
best regards
Tomasz
5th September 2010, 14:18
wysota

Re: memory leak - where?

Quote:

Originally Posted by Tomasz

My application should work for a long time without problems, but more it's works valgrind shows more memory leaks.

I don't think Valgrind will show you memory leaks while the program is running. A leak can only be detected with probability close to 100% when the application exits.

Quote:

I'm always closing database after using it with MyDatabse.close();

There is also QSqlDatabase::removeDatabase() that frees all the resources.

Quote:

Is there anything more I can do to make my application more reliable?

You need to interpret the memory leak report yourself and review your code to see if you are not leaking memory. Qt itself doesn't leak memory so if you really do have leaks (not that you think you do but that you are certain you do) then it's either in your code or in support libraries (such as db engines, font engines, etc.).
5th September 2010, 14:44
Tomasz

Re: memory leak - where?

Quote:

Originally Posted by wysota

I don't think Valgrind will show you memory leaks while the program is running. A leak can only be detected with probability close to 100% when the application exits.

You're right. I meant that it shows leaks after closing application.
I'll try QSqlDatabase::removeDatabase() and let know how it works.

thanks
best regards
Tomasz
5th September 2010, 15:19
wysota

Re: memory leak - where?

Quote:

Originally Posted by Tomasz

I'll try QSqlDatabase::removeDatabase() and let know how it works.

Don't expect miracles, it won't make your problems go away and from practical point of view the use of this method is meaningless as in your case you'd only use it when exiting the application anyway so it won't prevent the application from leaking memory.
5th September 2010, 21:20
Tomasz

Re: memory leak - where?
I think I've found problem. Here we've got code:
Code:

ok = bdb.open(); if (ok) { queryModel.clear(); queryModel.setQuery("SELECT * FROM notifi WHERE complete='0'", bdb); queryModel.clear(); // <----- with this everything is OK bdb.close(); }
And now my question - why if I close my database without clearing QSqlQueryModel strange things happens (data is still there but memory usage is still growing up each time function is executed)? I need to close database for other programs but i need to use data that I've just read from database to QSqlQueryModel.

thanks in advance
best regards
Tomasz
5th September 2010, 21:41
wysota

Re: memory leak - where?

Destructor of the model will call clear() for you so this is not a memory leak situation. Of course you shouldn't be closing a connection with an active query and you will get a warning on the console when doing so. You should clear all the queries and only then close the database connection.
5th September 2010, 23:47
Tomasz

Re: memory leak - where?

Quote:

Originally Posted by wysota

Of course you shouldn't be closing a connection with an active query and you will get a warning on the console when doing so. You should clear all the queries and only then close the database connection.

In this case I don't get any warning in my console. I'm only observing growing memory usage ('top' command), which disappears when I clean before closing. I'll think I need to learn more about using database in QT. I've got some questions about that problem but I'll search for answers in thread more connected with databases. Thanks!

best regards
Tomasz

Show 50 post(s) from this thread on one page