[mapserver] Java VM Crashes using the Mapscript API

[Umberto Nicoletti]

I'd suggest you open an issue on bugzilla, as the segfault should NEVER happen.

Regards,
Umberto

On 6/28/05, Christian Schroeder <mailings at abiwood99.de> wrote:
> Hello Benedikt!
> 
> Thank you very much for this tip,
> now the segfault does not seem to occour any more and our problem seems
> to be solved with that.
> 
> Thank you very much for your help!
> 
> Best Regards,
> Christian
> 
> 
> Benedikt Rothe schrieb:
> 
> >
> > the java-stacktrace shows, that the "delete" is called by from the
> > "finalize"-method, i.e. from the
> > garbage-collector.
> > our experience is, that calling delete directly from the java-servlet
> > is *much* safer.
> >
> > if we dynamically create mapserver-objects, we allway use code like this:
> > classObj cO = new classObj(...);
> > ..
> > // Do something with cO
> > ..
> > //now cO isn't used any more
> > cO.delete()
> >
> > same rule for layers etc.
> >
> > Benedikt
> >
> >
> >
> > UMN MapServer Users List <MAPSERVER-USERS at LISTS.UMN.EDU> schrieb am
> > 21.06.2005 17:21:39:
> >
> > > I'm forwarding this to the users list. Hopefully, Umberto will be able
> > > to provide some insight.
> > >
> > > cheers,
> > > Sean
> > >
> > > On Jun 16, 2005, at 5:08 PM, Christian Schröder wrote:
> > >
> > > > Dear Mr. Gillies,
> > > >
> > > > some weeks ago me and Florian Pepping contacted you because we had
> > > > problems using the Java Mapscript API. Thanks to you we could solve
> > > > these problems :-)
> > > >
> > > > Now we got our program doing what it's supposed to do but there is
> > > > still a big problem left which we were not able to solve yet:
> > > > We created a simple servlet which is created inside a Tomcat 5.0
> > > > Webserver. This servlet created a map image (png/jpg) and displays
> > > > some specified objects on the map. (We use it for location based
> > > > services --> "show me the position of the next printer").
> > > > After an irregular number of calls of our servlet which uses the Java
> > > > Mapscript API the complete Java VM and with it the Tomcat crashes. I
> > > > attached the error report below. The program works properly for a
> > > > number of calls (between 5 and 1000 :-) ) and after that it crashes.
> > > > We have tried several versions of the mapserver (4.4.1, 4.4.2, 4.2.4,
> > > > 4.6.1 RC1) and compiled the Java Mapscript Module with JDK 1.4.2 and
> > > > 1.5.0. We also configured mapserver using the --with-threads option,
> > > > but all this did not help. By the way the mapserv cgi-module works
> > > > properly.
> > > >
> > > > Do you have an idea for this?
> > > >
> > > > Thanks for your anxiety
> > > >
> > > > Christian & Florian
> > > > University of Paderborn, Germany
> > > >
> > > >
> > > > -------------------------------------------------------------------
> > > >
> > > > JavaMapscriptLoader: mapscript native library has been loaded.
> > > > * mapscript native library loaded *
> > > >
> > > > An unexpected exception has been detected in native code outside the
> > > > VM.
> > > > Unexpected Signal : 11 occurred at PC=0x3338268
> > > > Function=delete_classObj+0x8
> > > > Library=/usr/lib/libmapscript.so
> > > >
> > > > Current Java thread:
> > > > at edu.umn.gis.mapscript.mapscriptJNI.delete_classObj(Native
> > > > Method)
> > > > at edu.umn.gis.mapscript.classObj.delete(classObj.java:32)
> > > > at edu.umn.gis.mapscript.classObj.finalize(classObj.java:26)
> > > > at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method)
> > > > at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:83)
> > > > at java.lang.ref.Finalizer.access$100(Finalizer.java:14)
> > > > at
> > > > java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160)
> > > >
> > > > Dynamic libraries:
> > > > Can not get information for pid = 10558
> > > >
> > > > Heap at VM Abort:
> > > > Heap
> > > > def new generation total 1152K, used 135K [0x08ae0000, 0x08c20000,
> > > > 0x08fc0000)
> > > > eden space 1024K, 0% used [0x08ae0000, 0x08ae4078, 0x08be0000)
> > > > from space 128K, 100% used [0x08c00000, 0x08c20000, 0x08c20000)
> > > > to space 128K, 0% used [0x08be0000, 0x08be0000, 0x08c00000)
> > > > tenured generation total 15048K, used 13624K [0x08fc0000,
> > > > 0x09e72000,
> > > > 0x0cae0000)
> > > > the space 15048K, 90% used [0x08fc0000, 0x09d0e1c0, 0x09d0e200,
> > > > 0x09e72000)
> > > > compacting perm gen total 18432K, used 18373K [0x0cae0000,
> > > > 0x0dce0000,
> > > > 0x10ae0000)
> > > > the space 18432K, 99% used [0x0cae0000, 0x0dcd1618, 0x0dcd1800,
> > > > 0x0dce0000)
> > > >
> > > > Local Time = Tue Jun 14 15:32:19 2005
> > > > Elapsed Time = 246
> > > > #
> > > > # The exception above was detected in native code outside the VM
> > > > #
> > > > # Java VM: Java HotSpot(TM) Client VM (1.4.2_08-b03 mixed mode)
> > > > #
> > > > # An error report file has been saved as /tmp/hs_err_pid10558.log.
> > > > # Please refer to the file for further information.
> > > > #
> > > >
> > > > -------------------------------------------------------------------
> > > >
> > > > On Mar 22, 2005, at 12:02 PM, Florian Pepping wrote:
> > > >
> > > >> Dear Mr. Gillies,
> > > >>
> > > >> I'm a student of the University of Paderborn in Germany and
> > member of
> > > >> the project group "Location Based Services for Wireless Devices". In
> > > >> this project we try to position laptops and other WLAN-enabled
> > > >> devices using the signal strength of the WLAN. According to their
> > > >> position, we want to offer location based services to the persons
> > > >> using the devices (where I am; where's the next printer; is there a
> > > >> friend nearby)
> > > >>
> > > >> In order to do this, we want to use your mapserver and the Java
> > > >> Mapscript API to generate maps according to the actual position and
> > > >> situation. We like to customize the map of our building and add
> > > >> points, lines and so on.
> > > >>
> > > >> We have been able to compile the whole mapserver and the Java
> > > >> Mapscript API. A small Java example also works, which presents an
> > > >> unchanged map of our building.
> > > >>
> > > > > [...]
> > > >
>