[Gdal-dev] Re: Very odd problem SWIG & PERL

[jolma at cc.hut.fi]

I hope there is no problem exposing this to the gdal-list. The summary is: when
working with gdal+swig/perl always use "my" or explicitly undef any gdal objects
you have.

Look at http://mailman.cs.uchicago.edu/pipermail/swig/2001-April/002424.html

and the resulting thread. That's rather old but it seems there still isn't any
solution to this in swig/perl.

... or this is what I think this is, after poking around with Devel::Peek

Ari


On Fri, 21 Oct 2005 10:55:15 -0500 Kevin Ruland <kruland at ku.edu> wrote:

> 
> Ari,
> 
> I've cc'd Ethan (irc westside) just so he knows we're trying to do
> something about this.
> 
> I've reduced the buggy example to much less:
> 
> #!/usr/bin/perl
> 
> use ogr;
> $input = ogr::Open('./gdalautotest/ogr/data/poly.shp');
> $in_layer = $input->GetLayerByName('poly');  #  Ref line 1
> 
> $driver = ogr::GetDriverByName( 'MapInfo File');
> 
> #my $ot;   # Ref line 2
> $ot = $driver->CreateDataSource('./myoutput');
> print "After CreateDataSource\n";
>  
> #$ot = undef;  # Ref line 3
> 
> print "Exit\n";
> 
> 
> I slipped a printf in the perl/ogr_wrap.cpp file in the XS(
> _wrap_delete_DataSource) which did this:
> 
> printf( "Calling _wrap_delete_Datasource %x\n",arg1);
> 
> and reinstalled the perl module.  I did this to demonstrate what's
> going on.
> 
> The scripts creates two different DataSource objects:  $input and $ot. 
> We expect that both of these will be deleted when the program exits. 
> However, if you execute the program as it's written (I retyped so there
> might be some typo's), you will notice that only one DataSource is
> deleted ($input).
> 
> If you rerun with either Ref line 2 or Ref line 3 uncommented, then you
> will see the second destructor getting called.  Ref line 3 is pretty
> obvious because it immediately removes the reference and forces garbage
> collection.  I am uncertain why Ref line 2 corrects the problem.
> 
> The most interesting thing I discovered is if you comment out Ref line
> 1
> (and leave 2 & 3 commented out), then you will also see both
> destructors
> called.
> 
> I've duplicated this exact same program in the python bindings and it
> works as expected reguardless of which lines are commented in and out.
> 
> I attempted to create a test swig .i file which does not use gdal/ogr
> which replicates this problem but I have not yet been able to
> reproduce.
> 
> There might be some kind of memory corruption going on.  I've instered
> a
> bunch of diagnostics in both ogr.pm and ogr_wrap.cpp and see wierd
> things.
> 
> Kevin
> 
> Ethan Alpert wrote:
> 
> >
> >
> >Since I'm completely dumbfounded by the following problem I reaching
> for
> >straws in the hopes someone has had something similar happen.
> >
> >Here's some code that uses a swig generated module (hope the formating
> >works):
> >
> >#!/usr/bin/perl
> >
> >use ogr;
> >
> >$input = ogr::Open('./gdalautotest-1.3.1/ogr/data/poly.shp');
> >$in_layer = $input->GetLayerByName('poly');
> >$driver = ogr::GetDriverByName('MapInfo File');
> >$ot = $driver->CreateDataSource('./myoutput');
> >#my $ot = $driver->CreateDataSource('./myoutput');
> >$out_layer = $ot->CreateLayer('out',undef,$ogr::wkbPolygon);
> >
> >$in_defn= $in_layer->GetLayerDefn();
> >
> >
> >for($i=0; $i < $in_defn->GetFieldCount(); $i++) {
> >        $col = $in_defn->GetFieldDefn($i);
> >        $out_layer->CreateField($col,1);
> >}
> >
> >while($feat = $in_layer->GetNextFeature()) {
> >        $tmp = $feat->Clone();
> >        $out_layer->CreateFeature($tmp);
> >}
> >$out_layer->SyncToDisk();
> >
> >
> >This code produces bogus output. However if I remove the comment and
> >comment the line above it the code works. Now clearly this is *bad*
> perl
> >but the fact that using "my" in one place fixes it confuses me.
> >  
> >
>