[Marble-devel] Leak in GeoDataTrack?

[Josh Knox]

Hi,

While scouring my code for leaks, using valgrind, I found that creation of GeoDataTracks were dynamically allocating their GeoDataTrackPrivate *d;
I use alot of GeoDataTracks so this seems like a good thing to clean up.

The GeoDataTrack constructor simply does:

     GeoDataTrack::GeoDataTrack()
         : d( new GeoDataTrackPrivate() )
     {

     }

Unfortunately there's no destructor to clean this up, so it leaks.  I figure either clean it up in a destructor or wrap it in a "smart" pointer.


This test program demonstrates the issue when run under valgrind.

     #include <marble/GeoDataTrack.h>

     int main(int argc, char** argv) {
         Marble::GeoDataTrack foo;  // A stack allocation leaks memory
         Marble::GeoDataTrack* bar = new  Marble::GeoDataTrack();
         delete bar;                // leaks even if we delete it.
     };



Valgrind reports this:

     ==5264== HEAP SUMMARY:
     ==5264==     in use at exit: 10,182 bytes in 499 blocks
     ==5264==   total heap usage: 2,169 allocs, 1,670 frees, 145,104 bytes allocated
     ==5264==
     ==5264== 320 (72 direct, 248 indirect) bytes in 1 blocks are definitely lost in loss record 498 of 499
     ==5264==    at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
     ==5264==    by 0x5D94C9B: Marble::GeoDataTrack::GeoDataTrack() (GeoDataTrack.cpp:56)
     ==5264==    by 0x108E3D: main (testGeoDataTrack.cpp:6)
     ==5264==
     ==5264== 320 (72 direct, 248 indirect) bytes in 1 blocks are definitely lost in loss record 499 of 499
     ==5264==    at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
     ==5264==    by 0x5D94C9B: Marble::GeoDataTrack::GeoDataTrack() (GeoDataTrack.cpp:56)
     ==5264==    by 0x108E52: main (testGeoDataTrack.cpp:8)
     ==5264==
     ==5264== LEAK SUMMARY:
     ==5264==    definitely lost: 144 bytes in 2 blocks
     ==5264==    indirectly lost: 496 bytes in 16 blocks



Am I missing something or is this a bug? Is this addressed on a development branch? Should I send a patch if I fix it on my end?


Thanks!

Josh