SWIG mapscript critical problems!!!

[Steve Lime]

I was thinking more of a high level use case for testing then we implement as
necessary in the appropriate bindings. (that might be nice generally)

The problem is that users create oprhaned objects in absence of a parent correct
 - e.g. a layerObj without a mapObj.  I'm curious what users do with these objects 
once created and if it makes sense to even allow this behavior.

Are users creating, for example, a layerObj and then building it out and finally 
calling insertLayer to add it to a mapObj? That seems like the situtation where
ownership of memory would be an issue. Perhaps the insert methods need to
be changed (e.g. return the pointer to the inserted object which is a copy of
the original rather than dealing with typemaps for every language.

Steve

>>> "Tamas Szekeres" <szekerest at gmail.com> 6/17/2006 4:18:07 PM >>>
Steve,

Unfortunately it is not so easy to write generic test applications for all
of the swig bindings. It would require to rewrite the test for all of the
languages. However, it would be desirable in the future and could be
realized using a code generator (if any) that can translate a pseudocode to
the different languages.

This time all i can do is to interpret the problem, make the tests for C#,
creating a proposal for the fix (solely for C# or generally if possible) and
let the maintainers of the other languages decide if the problem applies to
them and they want to make their own tests. That was the purpose of this
thread was initially posted.

I cannot decide whether these issues apply to the PHP mapscript and i cannot
be sure about the other SWIG languages, because it would take a long time to
identify the differences and similarities between the several interface
implementations. The java binding seems to be similar to the C#
implementation, therefore the problems described here applies to java as
well.

Further on i will address the C# interface but one can easily interpret the
assumptions also for the others.

SWIG C# transforms the C structs to C# classes. All of these classes have a
reference to the native memory (called swigCPtr) that holds the wrapped C
struct.
The C# objects also have a flag (swigCMemOwn) that indicates that the memory
should be handled internally and destroyed during the object destruction.
If this flag is set the release of the memory will take place when the user
calls the predefinied Dispose method or when the C# object will not have any
further references and the garbage collector will destroy the object.

Both of the problems mentioned are dedicated to the improper handling of the
swigCMemOwn property. There are some cases when the referenced native memory
is normally destroyed by the mapserver code (within libmap.dll for example).
If swigCMemOwn is set the memory is candidate to be freed twice.

This situation can be produced by several different ways. <b>The reason of
these problems is that swig is not properly notified whether the ownership
of the memory should be transferred.</b>

1. Constructing layers from scratch (not declared by map file) is a common
situation for this issue.
We have the following constructors to create a layer or the subsequent
objects dynamically:

layerObj(mapObj map)
classObj(layerObj layer)
styleObj(classObj parent_class)

A new object is created with swigCMemOwn=true by default. If one gives not
null parameter for these constructors. The object (referenced by the
parameter) will take the ownership of the
memory referenced by the swigCPtr of the newly created object. Therefore
swigCMemOwn should be set to false (the object should be "disowned" in the
swig terminology) The current C# fix does exactly this by adding for
example:

%typemap(csconstruct, excode=SWIGEXCODE) layerObj(mapObj map) %{:
this($imcall, true) {
  if (map != null) this.swigCMemOwn = false;$excode
}
%}

2. Passing objects as parameters is the next area where improper ownership
may occur.
If a wrapped C struct has another struct or pointer to a struct that is not
readonly implies to create setter functions that have another object as a
parameter.
If the outer struct takes the ownership of this struct (and will free it
later) the object should be "disowned" by swig that is: swigCMemOwn should
be set to false in the C# wrapper object.

The more complicated case is if the inner element is a struct itself. SWIG
will make a raw copy of the struct, however the referenced inner elements of
the internal struct (char* represented strings for example) are not copied.

In my opinion it is the best to avoid such a situation mentioned before and
eliminate these elements from the interface if the functionality can be
achieved in other ways.
If the usage of the interface element is inevitable proper handling of the
object ownership is needed.
It must be noted that how an object handles an inner object is somewhat
apllication specific so these issues cannot be considered as a bug for the
SWIG interface generator.


Best Regards,

Tamas



-----Original Message-----
From: Steve Lime [mailto:Steve.Lime at dnr.state.mn.us] 
Sent: Friday, June 16, 2006 11:10 PM
To: szekerest at GMAIL.COM; MAPSERVER-DEV at LISTS.UMN.EDU 
Subject: Re: [UMN_MAPSERVER-DEV] SWIG mapscript critical problems!!!

Can we come up with a generic test case to apply in each language? It seems
like these issues would a result of architecture as opposed to SWIG itself
so 
PHP/MapScript should be looked at too. C# might just be better at bringing 
issues to the surface.

Steve

>>> Tamas Szekeres <szekerest at GMAIL.COM> 6/16/2006 11:09:44 AM >>>
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

-- 
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.0/368 - Release Date: 2006.06.16.
 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.0/368 - Release Date: 2006.06.16.