[UMN_MAPSERVER-USERS] python mapscript segfault

Tamas Szekeres szekerest at GMAIL.COM
Thu Nov 9 17:27:02 EST 2006


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
>



More information about the mapserver-dev mailing list