[gdal-dev] GetSpatialRef, OGRSpatialReference and memory leaks ?

[Andrew Bell]

Seems like it would depend on what you're doing with the pointer after you
return it.

On Sat, Aug 1, 2020, 5:50 AM Andrew C Aitchison <andrew at aitchison.me.uk>
wrote:

>
> I would like to define GetSpatialRef() for my raster driver as something
> like:
>
>      const OGRSpatialReference* GetSpatialRef() const override {
>          OGRSpatialReference* poSRS = new OGRSpatialReference();
>          if (poSRS->importFromEPSGA(27700)!=OGRERR_NONE)
>          {
>              delete poSRS;
>              poSRS = nullptr;
>          }
>          return poSRS;
>      }
>
> Unfortunately, valgrid reports that this leaks in the "new"
> on the line
>     OGRSpatialReference* poSRS = new OGRSpatialReference();
>
> On the other hand,
>
>      const OGRSpatialReference* GetSpatialRef() const override {
>          return new OGRSpatialReference("EPSG:27700");
>      }
>
> is no better:
> ==117785==
> ==117785== HEAP SUMMARY:
> ==117785==     in use at exit: 5,764 bytes in 24 blocks
> ==117785==   total heap usage: 7,363 allocs, 7,339 frees, 1,213,218 bytes
> allocated
> ==117785==
> ==117785== Searching for pointers to 24 not-freed blocks
> ==117785== Checked 3,635,216 bytes
> ==117785==
> ==117785== 596 (16 direct, 580 indirect) bytes in 1 blocks are definitely
> lost in loss record 14 of 16
> ==117785==    at 0x483BE63: operator new(unsigned long)
> (vg_replace_malloc.c:344)
> ==117785==    by 0x5E1D765: VRCDataset::GetSpatialRef() const (VRC.h:154)
> ==117785==    by 0x4ED723A: GDALInfo (gdalinfo_lib.cpp:333)
> ==117785==    by 0x10954D: main (gdalinfo_bin.cpp:213)
> ==117785==
> ==117785== 596 (16 direct, 580 indirect) bytes in 1 blocks are definitely
> lost in loss record 15 of 16
> ==117785==    at 0x483BE63: operator new(unsigned long)
> (vg_replace_malloc.c:344)
> ==117785==    by 0x5E1D765: VRCDataset::GetSpatialRef() const (VRC.h:154)
> ==117785==    by 0x4ED9203: GDALInfo (gdalinfo_lib.cpp:578)
> ==117785==    by 0x10954D: main (gdalinfo_bin.cpp:213)
> ==117785==
> ==117785== LEAK SUMMARY:
> ==117785==    definitely lost: 32 bytes in 2 blocks
> ==117785==    indirectly lost: 1,160 bytes in 10 blocks
> ==117785==      possibly lost: 0 bytes in 0 blocks
> ==117785==    still reachable: 4,572 bytes in 12 blocks
> ==117785==         suppressed: 0 bytes in 0 blocks
>
> This is with both gdal 3.0.4 and 3.1.2 on Ubunto 20.04.
>
> --
> Andrew C. Aitchison                                     Kendal, UK
>                         andrew at aitchison.me.uk
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20200801/f78a34c5/attachment.html>