SWIG mapscript critical problems!!!

[Tamas Szekeres]

Steve

Using constructors with parent objects (layerObj(mapObj map),
classObj(layerObj layer), styleObj(classObj parent_class)) is not
totally equivalent with using the corresponding insert methods.
The insertXXX methods are creating a copy of the objects before adding
them to the parent.
Therefore later the original object reference cannot be used to set
the properties of the object added.
This extra object creation does not happen when using the constructors
with the parent objects given. I am considering the latter as the
preferred way for adding inline layers (and the user like to use this
way as i can see). However the ownership of the native memory should
be handled properly as i have mentioned in the previous postings.

Best Regards,

Tamas


2006/6/19, Steve Lime <Steve.Lime at dnr.state.mn.us>:
> 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.
>
>
>