[gdal-dev] some problem in python bindings

[Ari Jolma]

Howard Butler wrote:
> On May 20, 2010, at 7:48 AM, Vincent Schut wrote:
>   
>> svn and I don't remember this happening earlier), there is a problem with the python swig bindings when doing this:
>>
>> data = gdal_array.BandReadAsArray(gdal.Open(filename).GetRasterBand(1))
>>     
> This is a consequence of the Python bindings historically expecting users to manage their own memory.  If operation chaining such as the first one works, it's a happy circumstance, but don't expect it to work always or even in most cases.  As to whether or not we fix it, I think yes, we'll take a patch if it's proven to work. 
>   

The Perl bindings take care of this by maintaining within Dataset class 
a global variable (hash) BANDS, which keeps alive all dataset objects 
that have alive band objects. In the destructor of the Band class the 
entry of the band object is deleted from the above hash and thus the 
dataset object may also be released. Thus code like

$data = Geo::GDAL::Open($filename)->GetRasterBand(1)->ReadTile;

for (@$data) {
    print "@$_\n";
}

does not cause a segfault. (The above code prints out all the contents 
of the band)

I try very hard to make it impossible to cause a segfault with GDAL Perl 
bindings as they are a major inconvenience for users and developers. 
Even a bad error message is much better.

Ari