SWIG mapscript critical problems!!!

[Tamas Szekeres]

Umberto,

All of the problems i have mentioned are properly identified and can
be handled and no further investigations should be made.

1. The first one is the constructors of layerObj, classObj, and
styleObj have already fixed for C# upon a previous user request. This
solution could be made for the other bindings as well. See csmodule.i
for more details. Despite of this fix reported as working i would
prefer a safer and more clear approach if we would like to create an
object and immediately add it to a parent like:

mapObj map = new mapObj("mymap.map");
layerObj newlayer = map.AddNewLayer();

Objects returned are properly "disowned" by SWIG and the finalization
of newlayer will not destroy the native memory referenced by the
object. I consider these members are writable is not intentional.
(members are exposed as writable by default).

2. The other problem is that mapscript is exposing some object members
as writable that theoretically should not be writable. (See my
previous post)
For example layerObj.map is handled internally and is solely for
getting the reference of the parent object.
layerObj.metadata is a hashtable which is already created by
initlayer. Why should we expose this member as writable? Users should
only add and remove elements on it.


I agree that these are not the only problems so further investigations
should be made.

Tamas

PS: Did you step forward with the getFeature issue?


2006/6/20, Umberto Nicoletti <umberto.nicoletti at gmail.com>:
> Tamas,
> those problems do exist in Java Mapscript too (see Benedikt's earlier
> post)  and I believe they exist in every mapscript with a gc.
>
> In my opinion we should distinguish two main common usage scenarios:
>
> 1) apps that reimplement the functionality of the mapserver cgi and
> mainly display an existing map file
> 2) apps that attempt to go beyond the basic and build maps, layers,
> classes, etc at runtime
>
> In the first case Java, C# and probably other mapscripts are mature
> enough to allow their use in production environment. Garbage
> collection will work and no memory leaks occur.
>
> The latter case is where we are stuck at the moment as we're having a
> real problem with memory management.
> First of all I we should make end users aware of these issues by
> keeping a 'mapscript state uf the union' page on mapserver web site
> describing what is safeto do and what is not. This will create less
> confusion and frustration among our users (and allows for RTFM replies
> ;-)).
> Then we should google the web to see how others are handling similar
> problems and take inspiration from what we see. It also probably needs
> an rfc of its own.
>
> Umberto
>
> On 6/16/06, Tamas Szekeres <szekerest at gmail.com> wrote:
> > Developers,
> >
> > Along with the recent postings on the user's list some of the folks
> > are complaining about funky
> > segfaults, memory reference exceptions when using some of the mapscript objects.
> >
> > I have found the following problems and would like to know if these
> > issues apply to the other languages or not.
> >
> > http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=1803
> > http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=1743
> >
> > Best Regards,
> >
> > Tamas
> >
>