[Gdal-dev] OGR Memory leak

[Chapman, Martin]

I did some tests with OGR executing queries on a layer with ExecuteSQL()
and found that there is a memory leak occurring when you re-run that
query many times.  I am calling ReleaseResultSet() between each
iteration, and I'm deleting the features objects after I use them.  I
also ran a test that only does the query and doesn't ask for any
features and there was still a leak.  My test consisted of 100
concurrent users (synchronized) over 10000 iterations.  Watching the
private bytes of my process shows a slow but steady growth of memory
allocation with no de-allocation.  When I comment out the call to
ExecuteSQL() the problem goes away.  I also tried to use the GetLayer()
function to retrieve the table followed by calls to SetAttributeFilter()
and the result was less leakage but it still has a leak.  Has anyone
else ran into this problem?  I'm running the test on Windows XP and the
data source is an ESRI shape file with a few hundred records.

 

The code is like this:

 

 

m_pLayer = m_pDataSource->ExecuteSQL(m_sStatement.c_str(), NULL, "");

if (m_pLayer == NULL) 

      throw CPLGetLastErrorMsg();

 

m_pDataSource->ReleaseResultSet(m_pLayer);

m_pLayer = NULL;

 

 

// also leaks, but not as much

 

 

m_pLayer = m_pDataSource->GetLayer(0);

if (m_pLayer == NULL) 

      throw CPLGetLastErrorMsg();

 

OGRErr err = m_pLayer->SetAttributeFilter(m_sStatement.c_str());

if (err != OGRERR_NONE) throw CPLGetLastErrorMsg(); 

 

err = m_pLayer->SetAttributeFilter(NULL);

if (err != OGRERR_NONE) throw CPLGetLastErrorMsg(); 

 

 

Can someone else do a test to confirm that there is truly a leak? ...
Frank? ... anyone? ... Ferris Bueller?

 

Thanks,

Martin

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20051202/b864ea05/attachment.html