SWIG mapscript critical problems!!!

[Sean Gillies]

On Jun 19, 2006, at 8:56 AM, Steve Lime wrote:

> 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=20
> 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=20
> 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

Steve, that is exactly what the insert methods do. They make a copy  
and return a reference.

Sean

>
>>>> "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=3Dtrue 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=3DSWIGEXCODE) layerObj(mapObj map) %{:
> this($imcall, true) {
>   if (map !=3D null) this.swigCMemOwn =3D 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]=20
> Sent: Friday, June 16, 2006 11:10 PM
> To: szekerest at GMAIL.COM; MAPSERVER-DEV at LISTS.UMN.EDU=20
> 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=20
> PHP/MapScript should be looked at too. C# might just be better at =
> bringing=20
> 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=3D1803=20
> http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=3D1743=20
>
> Best Regards,
>
> Tamas
>
> --=20
> 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.
> =20
>
> --=20
> 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.
> =20

---
Sean Gillies
http://zcologia.com