Hi,

I've been profiling my code using valgrind....
(using marble built from latest source, ubuntu 12.04)

It appears that just instantiating a GeoDataCoordinates causes a chunk of memory leakage.

Here's my test program:

Code: Select all

#include <marble/GeoDataCoordinates.h>
using namespace Marble;
int main(int argc, char** argv)
{
    const GeoDataCoordinates bedfordnh(-71.46008,
                                                                 42.93231,
                                                                 90.0, GeoDataCoordinates::Degree);
}


Running under valgrind generates lots of errors similar to this:

==13675== 8 bytes in 1 blocks are definitely lost in loss record 384 of 480
==13675== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==13675== by 0x4F8358F: _GLOBAL__sub_I_SearchResultsTagHandler.cpp (SearchResultsTagHandler.cpp:40)
==13675== by 0x400F305: call_init.part.0 (dl-init.c:85)
==13675== by 0x400F3DE: _dl_init (dl-init.c:52)
==13675== by 0x40016E9: (in /lib/x86_64-linux-gnu/ld-2.15.so)
==13675==

And the final summary is:

==13675== LEAK SUMMARY:
==13675== definitely lost: 2,832 bytes in 354 blocks
==13675== indirectly lost: 0 bytes in 0 blocks
==13675== possibly lost: 0 bytes in 0 blocks
==13675== still reachable: 6,694 bytes in 126 blocks
==13675== suppressed: 0 bytes in 0 blocks
==13675== Reachable blocks (those to which a pointer was found) are not shown.
==13675== To see them, rerun with: --leak-check=full --show-reachable=yes
==13675==
==13675== For counts of detected and suppressed errors, rerun with: -v
==13675== ERROR SUMMARY: 354 errors from 354 contexts (suppressed: 2 from 2)

I looked at a few of the errors and it seems to be due to dynamic allocations done while creating static objects.
Also note that if I create 2 GeoDataCoordinates the leak count stays the same. So it seems like a one time hit in this case.

This is the most trivial case. I've got some slightly more complex code that shows even more errors from valgrind.

So, I guess my question is, how stable is marble during runtime? Can I expect (otherwise non-leaky) apps written using it to run for extended periods of time without exhausting system memory?

I'm sure some of these issues are known. Is there work going on to address the leakyness? Is there somewhere I could jump in and help with this?

Thanks!

josh wrote:So, I guess my question is, how stable is marble during runtime? Can I expect (otherwise non-leaky) apps written using it to run for extended periods of time without exhausting system memory?

Absolutely. We're running Marble (stable and unstable versions) at work embedded in a variety of applications and didn't have any leak problems (read: memory usage increasing over time) so far.

josh wrote:I'm sure some of these issues are known. Is there work going on to address the leakyness? Is there somewhere I could jump in and help with this?

Given that it works well in practice it doesn't have a too high priority in our TODO list. However, patches to improve/fix it would still be appreciated, be it just to have less noise in valgrind.
A good starting point should be the tests in tests/. You can run all via 'make test' or individual ones directly from the build directory (they're not installed). Requires the Qt only version IIRC (cmake -DQTONLY=TRUE). For fixing the issues have a look at the classes in src/lib/geodata/data, especially their private classes. They're not trivial though due to http://techbase.kde.org/Policies/Librar ... D-Pointers