memory leak - where?

[wysota]

Except the database issue, yes. But in general it's best to run your code through memory leak detection tool such as valgrind and see what it has to say.

[Tomasz]

I'll check it with valgrind. Is it necessary to use removeDatabase if I'm adding it only once at the beginning and then only using open/close on that database? Should I remove it and add it again after every open/close cycle?

thanks in advance
best regards
Tomasz

[wysota]

If you add it once then you remove it once. You said your application was increasing its memory usage and you gave the code snippet where you suspected the leak to be so I assumed it was being ran multiple times. We don't consider a leak something that lives throughout the whole life of the application and is not deleted anywhere (although it's still considered "improper"). A leak is when you repeat this process thoughout the life of the application, like so:

for(int i=0;i<10;i++){
  QString *var = new QString("xxx"); // memory is allocated 10 times and never released although the variable is not reachable anymore
}

for(int i=0;i<10;i++){
  QString *var = new QString("xxx"); // memory is allocated 10 times and never released although the variable is not reachable anymore
}

To copy to clipboard, switch view to plain text mode 

[Tomasz]

I've used valgrind, and it says:

LEAK SUMMARY:
definitely lost: 768 bytes in 4 blocks
indirectly lost: 2,840 bytes in 141 blocks
possibly lost: 1,119,616 bytes in 4,885 blocks
still reachable: 585,094 bytes in 5,456 blocks
suppressed: 0 bytes in 0 blocks

LEAK SUMMARY:
definitely lost: 768 bytes in 4 blocks
indirectly lost: 2,840 bytes in 141 blocks
possibly lost: 1,119,616 bytes in 4,885 blocks
still reachable: 585,094 bytes in 5,456 blocks
suppressed: 0 bytes in 0 blocks

To copy to clipboard, switch view to plain text mode 

Maybe I can post full code of my app (it's not long) and someone could tell me what I'm doing wrong?

thanks in advance
best regards
Tomasz

P.S. Even if I run the simplest application valgrind says that some memory is lost, but not as much as above.

[wysota]

Rerun valgrind with --leak-check=full --show-reachable=yes

[Tomasz]

I've ran it with that options for a while and it says:

LEAK SUMMARY:
definitely lost: 1,792 bytes in 8 blocks
indirectly lost: 8,400 bytes in 418 blocks
possibly lost: 5,756,014 bytes in 7,557 blocks
still reachable: 1,967,661 bytes in 8,582 blocks
suppressed: 0 bytes in 0 blocks

LEAK SUMMARY:
definitely lost: 1,792 bytes in 8 blocks
indirectly lost: 8,400 bytes in 418 blocks
possibly lost: 5,756,014 bytes in 7,557 blocks
still reachable: 1,967,661 bytes in 8,582 blocks
suppressed: 0 bytes in 0 blocks

To copy to clipboard, switch view to plain text mode 

[SixDegrees]

I've ran it with that options for a while and it says:

LEAK SUMMARY:
definitely lost: 1,792 bytes in 8 blocks
indirectly lost: 8,400 bytes in 418 blocks
possibly lost: 5,756,014 bytes in 7,557 blocks
still reachable: 1,967,661 bytes in 8,582 blocks
suppressed: 0 bytes in 0 blocks

LEAK SUMMARY:
definitely lost: 1,792 bytes in 8 blocks
indirectly lost: 8,400 bytes in 418 blocks
possibly lost: 5,756,014 bytes in 7,557 blocks
still reachable: 1,967,661 bytes in 8,582 blocks
suppressed: 0 bytes in 0 blocks

To copy to clipboard, switch view to plain text mode 

Well, it says a good deal more than that. Valgrind gives you a detailed report not only on the total amount of memory leaked, but where it was leaked, right down to the line number. You'll want to compile in debug mode to get the best report, but even without debugging information it's usually possible to track down the portion of code responsible for a leak.

Read through the valgrind documentation so you know what you're looking at.

[Tomasz]

Well, it says a good deal more than that.

Yes, It says really a lot of things. Sometimes it says about errors even in 'clean' application (window only) just created in Qt Creator. I don't have a lot of experience with valgrind, I'm reading documentation but still have no idea how to track that leaks. Code looks fine for me.

thaks in advance
best regards
Tomasz

[wysota]

Sometimes you can get false positives so it's important to understand why certain things are reported. But you should get a very detailed output with a place in code and reason for every leak.

[Tomasz]

Report like this?

==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)

==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)

To copy to clipboard, switch view to plain text mode 

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

[SixDegrees]

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.

[Tomasz]

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