OGR OGDI Driver not releasing OGDI layers

[Kevin.Wertman@…]

The OGROGDIDataSource and OGROGDILayer are not calling cln_ReleaseLayer, which
is causing file handles to be left open, eventually causing the number of open
file handles to exceed the number allowed to the process by the operating
system.   Also causes some memory issues, although not as severe.

In the current code base, ResetReading() on the OGROGDILayer blindly calls
cln_SelectLayer.   I've put in some logic so that the OGROGDIDataSource tracks
the currently selected layer and releases it before selecting the new layer.  
This solves the immediately file handle/memory leak problem.

[Kevin.Wertman@…]

OGDI cln_ReleaseLayer patch

[warmerdam]

Kevin,

I'm having problems reproducing this problem.  I tried running the command

  ogrinfo -ro $VRFURL 'orcharda@veg(*)_area' 'ruinsp@pop(*)_point'

under valgrind in the hopes it would show the leak, but it did not. 

What would I need to do to see the leak?

[Kevin.Wertman@…]

(In reply to comment #2)
> Kevin,
> I'm having problems reproducing this problem.  I tried running the command
>   ogrinfo -ro $VRFURL 'orcharda@veg(*)_area' 'ruinsp@pop(*)_point'
> under valgrind in the hopes it would show the leak, but it did not. 
> What would I need to do to see the leak?

Hi Frank,

What we are doing is opening multiple VPF OGRDataSources and iterating through 
all the layers (ResetReading() gets called more than a few times for each 
layer), and all the features within that layer - so every feature table is 
getting opened.   We are destroying the previous OGRDataSource before opening 
the next one with a different VPF database.

I'll see if I can recreate it using one of the ogr utilities or write up a test 
case that demonstrates it, but I may not be able to get to it in the next few 
days.

Thanks,
Kevin

[Even Rouault]

I've tried with a modified version of test_ogrsf that loops forever and see no issue. Closing