[gdal-dev] memory leak in GRIB reader (with Python bindings)

Chris Barker chris.barker at noaa.gov
Thu May 24 15:55:15 EDT 2012


Hi folks,

I"m finding what appears to be a memory leak, using the GRIB reader,
with the python bindings.

What I'm trying to do is read the data one band at a time, then throw
it away and read the next band -- there are 1129 bands in the file at
hand, and I can't hold it all in memory (32 bit still...)

However, when I do this, memory use just keeps climbing.

Should the memory be freed? I would expect so.

I'm using RasterBand.ReadAsArray()

Is this a leak? or is supposed to keep it around in memory?

Either way, is there a way to force it to release that memory (I"m
already doing and exlicite del and gc.collect call, so I dont think
it's a python reference counting issue)

I've enclosed a simpel test script -- watch the memory climb.

The data file is to big (186MB) to enclose here, you can get it here:

http://nomads.ncep.noaa.gov/pub/data/nccf/com/cfs/prod/cfs/cfs.20120522/18/time_grib_01/ocnu5.01.2012052218.daily.grb2

If you want to give this a try.


(note -- Grib giving some pretty good compression -- this climbs to
2.3GB when I read it)

I could actually live with the 2.3GB -- but in my real use case, I'm
reading two of these at the same time, so I max out what I can do with
32 bit python...

GDAL 1.8.1
Python 2.7 (32 bit Intel)
OS-X 10.6
I think it's the Kyng Chaos build of GDAL.

Thanks,
   -Chris









-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov


More information about the gdal-dev mailing list