python mapscript segfault

Tamas Szekeres szekerest at GMAIL.COM
Thu Nov 9 15:47:04 EST 2006


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-users mailing list