SWIG mapscript critical problems!!!
Umberto Nicoletti
umberto.nicoletti at GMAIL.COM
Thu Jun 22 10:18:06 EDT 2006
Tamas,
today I was writing a Java test case for the issues you have mentioned
and eventually found out that in Java I don't get segfaults or jvm
crashes, just null pointer exceptions.
I attach the test case source and its output:
Deleting layer # I have modified the swig wrapper so that when an
object is gced I know it
layer2=Layer 0
clazz2=Clazz 0
Deleting layer
Deleting layer
ERROR:layer2 is null # I thought I'd get a segfault here !!??
ERROR:clazz2 is null # and here too
Please note the last two lines (thiose starting with ERROR): while
that is indeeed an error because I should get the layer and class I
just added, the fix is straightforward: just populate the pointer to
the parent object in the swig glue code:
Index: ../swiginc/layer.i
===================================================================
RCS file: /data2/cvsroot/mapserver/mapscript/swiginc/layer.i,v
retrieving revision 1.23
diff -C3 -r1.23 layer.i
*** ../swiginc/layer.i 17 May 2006 15:26:21 -0000 1.23
--- ../swiginc/layer.i 22 Jun 2006 14:07:34 -0000
***************
*** 118,123 ****
--- 118,124 ----
int insertClass(classObj *classobj, int index=-1)
{
+ classobj->layer=self;
return msInsertClass(self, classobj, index);
}
So is Java behaving different from C# or am I just missing the obvious here?
You can compile and run the example with following command:
javac -classpath ./:examples/:./mapscript.jar -d examples/
examples/MemoryMngTest.java && java -classpath
./:examples/:./mapscript.jar -Djava.library.path=. MemoryMngTest
Regards,
Umberto
On 6/22/06, Umberto Nicoletti <umberto.nicoletti at gmail.com> wrote:
> On 6/22/06, Tamas Szekeres <szekerest at gmail.com> wrote:
> > Umberto,
> >
> > 2006/6/22, Umberto Nicoletti <umberto.nicoletti at gmail.com>:
> > >
> > > This solution implies an API change which I don't favour. I like
> > > better the solution you have already implemented in csmodule.i but it
> > > needs to be extended to other languages and to other functions like
> > > insertClass, setMetadata, etc.
> > > Btw have you seen how the ruby people are doing it?
> > > http://www.swig.org/Doc1.3/Ruby.html#Ruby_nn57
> > >
> >
> > 1. In this case SWIGTYPE DISOWN is not usable since the behaviour
> > depend on the parameter. If null parameter is given for the
> > constructor disowning the internal memory will result in a memory
> > leak.
> > 2. I wonder is DISOWN works for C# by looking a the documentations and
> > the swig source tree.
> >
>
> I was referring to that smart object tracking which would ensure that
> even object identity works,but that's not the point here. It seems to
> have itw own set of problems though:
>
> http://comments.gmane.org/gmane.comp.programming.swig/7813
>
> > > > For example layerObj.map is handled internally and is solely for
> > > > getting the reference of the parent object.
> > >
> > > In Java you can't set the map reference, only get it.
> > >
> >
> > Ok, i was thinking of legendObj.map for example, apologies.
> >
> > >
> > > Because not all mapscript objects are properly set up: for instance
> > > webObj until recently did not have a constructor which invoked initWeb
> > > so the metadata had to be set from Java. This can be solved of course,
> > > but it would break backwards compatibility (API change).
> > >
> >
> > I would discourage to maintain unintentionally exposed interface
> > elements just for retaining the backward compatibility. Users should
> > not create objects from scratch and add them to a parent object is it
> > has already been constructed during the parent object creation.
> >
>
> I agree. We could make those functions deprecated and then remove them
> in a release or two.
> We need to document this on the web site (you see I'm sticking with my
> ideas ;-))
>
> Best regards,
> Umberto
>
> >
> > Regards,
> >
> > Tamas
> >
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MemoryMngTest.java
Type: text/x-java
Size: 2252 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20060622/06e37cf7/MemoryMngTest.bin
More information about the mapserver-dev
mailing list