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

[Kevin Ruland]

Ari,

The best practice so far is to 'use strict' and use 'my'.  Also, this 
appears to really be a swig bug and is very similar to this one:

https://sourceforge.net/tracker/index.php?func=detail&aid=1325221&group_id=1645&atid=101645

Even though this particular bugzilla was closed as invalid, I'm still 
trying to get a perl wizard there to look into it.

Kevin

jolma at cc.hut.fi wrote:

>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.
>>> 
>>>
>>>      
>>>