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

[Ari Jolma]

On Sun, 23 Oct 2005 12:45:35 -0500 Kevin Ruland <kruland at ku.edu> wrote:

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


Looks more like a swig "feature":
http://mailman.cs.uchicago.edu/pipermail/swig/2001-April/002428.html

Swig makes the object as a kind of russian wood doll. In this case the objects
are created in an equal way in ogr_wrap.cpp and they result in similar perl
variables (when examined with Devel::Peek) but for some reason Perl deletes the
inside doll first (of the 2nd object) if left for the global destructor (and I
don't think Perl can be blamed for doing so) and that causes Swig's (too fragile
in this sense seems to me) system to fail. This is also very similar to the
reference "feature" we have (keep the parent alive as long as children are
used). I don't think that we can do much with this now.

Ari


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

-- 
Prof. Ari Jolma
Kartografia ja Geoinformatiikka / Cartography and Geoinformatics
Teknillinen Korkeakoulu / Helsinki University of Technology
POBox 1200, 02015 TKK, Finland
Email: ari.jolma at tkk.fi URL: http://www.tkk.fi/~jolma