[Marble-devel] Leak in GeoDataTrack?

[Josh Knox]

Looks like valgrind is confusing me.

The GeoDataTrack code cleans things up properly. I see that the GeoDataTrack base class, (GeoDataGeometry) destructor deletes d using a reference counting scheme and appears to work.

It is not clear to me why valgrind reports it as a leak though. :(



On 05/06/2014 04:28 PM, Josh Knox wrote:
> 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
> _______________________________________________
> Marble-devel mailing list
> Marble-devel at kde.org
> https://mail.kde.org/mailman/listinfo/marble-devel
>