[UMN_MAPSERVER-USERS] python mapscript segfault

[Tamas Szekeres]

I'm afraid this kind of problem should be handled at the binding
language side where the ownership of the underlying memory is
controlled.
I'm sure in that Java has an exact equivalent of the csconstuct
typemap (javaconstruct as far as I remember). However I'm not so
familiar with the others but I guess they also have the corresponding
options.

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