[UMN_MAPSERVER-USERS] python mapscript segfault

[Steve Lime]

Perhaps the various binding owners could get together on IRC to
formulate
a plan for straightening this out for 5.0?

Steve

>>> Tamas Szekeres <szekerest at GMAIL.COM> 11/09/06 5:15 PM >>>
And we should also reconsider all of the functions with objects as
parameters or propertyes of object types whether the ownership should
be taken or not.

Tamas



2006/11/9, Steve Lime <Steve.Lime at dnr.state.mn.us>:
> Can that same typemap be used for the other languages or is that C#
> specific? I can't tell
> by looking at it. If so could a global typemap be created for ALL
> languages bindings?
>
> Steve
>
> >>> Tamas Szekeres <szekerest at GMAIL.COM> 11/9/2006 4:27:02 PM >>>
> Developers,
>
> Our misery has been started by introducing the SWIG layerObj,
> classObj, styleObj constructors according to:
>
> http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=358
>
> followed by the following issues might be related to it:
>
> http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=880
> http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=1400
> http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=1743
> http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=1841
>
> I consider this issue as fixed for c# (see the thread above for the
> corresponding typemaps) and would motivate the owners of the other
> language bindings to make a fix as soon as possible to avoid myriads
> of the further bug reports.
>
> Best Regards,
>
> Tamas Szekeres
>
>
>
>
> 2006/11/9, Tamas Szekeres <szekerest at gmail.com>:
> > 2006/11/9, John Cartwright <John.C.Cartwright at noaa.gov>:
> > > Hello All,
> > >
> > > I'm trying to use python mapscript (4.10.0) on MacOS 10.4 to
create
> a
> > > map dynamically and output the image.  Code seems to segfault at
> the
> > > termination of the program.  Can anyone see what I'm doing wrong
> or
> > > suggest a method of tracing the problem?
> > >
> > > Thanks!
> > >
> > > -- john
> > >
> > >
> > > import mapscript;
> > >
> > > map = mapscript.mapObj()
> > > map.name = "CustomMap"
> > > map.setSize(600,300)
> > > map.setExtent(-180.0,-90.0,180.0,90.0)
> > > map.imagecolor.setRGB(180,180,250)
> > > map.units = mapscript.MS_DD
> > >
> > > layer = mapscript.layerObj(map)
> > > layer.name = "countries"
> > > layer.type = mapscript.MS_LAYER_POLYGON
> > > layer.status = mapscript.MS_DEFAULT
> > > layer.data = "/usr/local/shapefiles/country.shp"
> > >
> > > class1 = mapscript.classObj(layer)
> > > class1.name = "Countries"
> > >
> > > style = mapscript.styleObj(class1)
> > > style.outlinecolor.setRGB(100,100,100)
> > > style.color.setRGB(200,200,200)
> > >
> > > map_image = map.draw()
> > > filename = 'test.' + map_image.format.extension
> > > map_image.save(filename)
> > >
> >
> > I've notified the developers about this issue long ago but I can see
> I
> > should repeat the problem again.
> > So this is definitely a mapserver issue has been identified
> originally
> > for C# descibed in the following bug:
> >
> > http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=1743
> >
> > As looking into the code the problem applies to C# Java and Python
> but
> > might apply to the other
> > SWIG variants as well.
> >
> > This problem is related to the improper handling of the ownership of
> > the memory. For example when calling
> >
> > mapscript.layerObj(map) the map object will take the ownership of
> the
> > constructed object so the internal state
> > of the layer object should be changed accordingly. That is: setting
> > swigCMemOwn = false for Java and C#.
> >
> > The most awkward thing that we cannot workaround this issue
> > declaratively (like using DISOWN typemaps for example)
> > because the ownership should not be transferred when the constructor
> > is called with null.
> >
> > For the C# binding we could use the following fix (in csmodule.i):
> >
> >
> > %typemap(csconstruct, excode=SWIGEXCODE) layerObj(mapObj map) %{:
> > this($imcall, true) {
> >   if (map != null) this.swigCMemOwn = false;$excode
> > }
> > %}
> > %typemap(csconstruct, excode=SWIGEXCODE) classObj(layerObj layer)
> %{:
> > this($imcall, true) {
> >   if (layer != null) this.swigCMemOwn = false;$excode
> > }
> > %}
> > %typemap(csconstruct, excode=SWIGEXCODE) styleObj(classObj
> > parent_class) %{: this($imcall, true) {
> >   if (parent_class != null) this.swigCMemOwn = false;$excode
> > }
> > %}
> >
> > John,
> > Instead of the code above would you try using insertLayer,
> insertClass
> > and insertStyle
> > with the newly created layer class and style objects constructed
> using
> > null parameter?
> >
> >
> > Besides this problem I could mention at least 2 more use cases where
> > the SWIG generated wrappers will definitely fail.
> > Needless to say that all of these issues are dedicated to the
> improper
> > handling the ownership of the memory holded by
> > the wrapper classes. Recently I've fixed one exclusively for the
> > GDAL-SWIG C# and posted the fix to the SWIG guys
> > ("Preventing from the early garbage collection of the C# object").
> >
> > However I've got not answer so far.....  :-(
> >
> >
> > Best Regards,
> >
> > Tamas Szekeres
> >
>