[gdal-dev] Memory leaks when using SQL queries with shapefiles

[Even Rouault]

Selon Pierluigi Guasqui <guasqui at actgate.com>:

> Hello,
>
> I am experiencing a big memory allocation (with no subsequent memory
> release) when using SQL queries with shapefiles. This is a sample code
> that triggers this problem:
>
>      OGRRegisterAll();
>
>      // opening shapefile data source
>      const char *fname = "path/to/shapefile.shp";
>      OGRDataSource *poDS;
>      poDS = OGRSFDriverRegistrar::Open( fname, FALSE );
>
>      if( poDS == NULL )
>      {
>          fprintf( stderr, "%s: could not open input file\n", fname );
>          return -1;
>      }
>
>      // creating the spatial filter
>      OGRLineString regionPolygon;
>      OGRRawPoint *pointsList = new OGRRawPoint[5];
>      pointsList[0].x = -180; pointsList[0].y =  90;
>      pointsList[1].x =  180; pointsList[1].y =  90;
>      pointsList[2].x =  180; pointsList[2].y = -90;
>      pointsList[3].x = -180; pointsList[3].y = -90;
>      pointsList[4].x = -180; pointsList[4].y =  90;
>      regionPolygon.setPoints(5, pointsList);
>      delete[] pointsList;
>
>      // executing the query
>      const char *query = "SELECT * FROM table_name WHERE some_field LIKE
> '%bla%' ORDER BY some_other_field";
>      OGRLayer *rs = poDS->ExecuteSQL( query, &regionPolygon, NULL );
>
>      // releasing memory
>      poDS-> ReleaseResultSet( rs );
>      OGRDataSource::DestroyDataSource( poDS );
>
> With a 100.000 records shapefile "ExecuteSQL" has allocated over 300
> MBytes of memory with no deallocation when calling "ReleaseResultSet".
>
> The memory leak is triggered only when "ExecuteSQL" is called with a
> spatial filter (even trivial as shown in the above code) and the SQL
> query contains a 'WHERE' clause and an 'ORDER BY' clause. Is this a bug?
>
> I am using GDAL 1.9.1 under Windows platform.
>
> Any help would be really appreciated!

Pierluigi,

I have not a dev environmenet at the moment to investigate that, but could you
open a ticket in GDAL Trac with all the details so it does not get lost ?

Are you positive that, all other things unchanged, the presence of the spatial
filter makes a difference ? I'm not sure how you check on Windows if the memory
is really released (if you put your code in a while(1) {} loop, does the memory
used by the process increase at each iteration ?).

I also suspect that your spatial filter will not do what you would (probably)
expect from it. The geometry of the filter is a LINESTRING, not a POLYGON. So it
will only filter geometries that intersect the line, not geometries that are
fully inside it.

Best regards,

Even