Opened 18 years ago

Last modified 18 years ago

#613 closed defect (fixed)

memory leaks from using importFromESRI

Reported by: ben@… Owned by: warmerdam
Priority: high Milestone:
Component: default Version: unspecified
Severity: normal Keywords:
Cc:

Description

When i call:  OGRSpatialReference::importFromESRI()
it calls:  InitDatumMappingTable()

which allocates a bunch of stuff, including a big array like this:
    papszDatumMapping = (char
**)CPLCalloc(sizeof(char*),nMaxDatumMappings*3);

This memory never seems to get freed.  I looked for, but didn't find, a
function like FreeDatumMappingTable().

Frank says: There does not seem to be a way around this.  If you file a bug on
it, I will try to rectify this by the 1.2.3 release.

It's not that this one-time leak is important by itself, but by introducing a
batch of leaks, it makes it harder for me to the _other_ leaks in my GDAL-using app.

Change History (1)

comment:1 by warmerdam, 18 years ago

Ben,

I have added a new OSRCleanup() function responsible for cleaning up
OGRSpatialReference related memory or anything the coordinate system
API.  Currently just the datum table, and ensure that CSV datasets are
cleared. 

The GDALDeriverManager destrutctor will call this or you can call it 
directly.

This will be in the next release (either 1.2.2.1 or 1.2.3). 

Note: See TracTickets for help on using tickets.