On Mon, 2006-02-27 at 15:36, Alessandra Forti wrote:
> PS there is also this at the end of the error
>
> #
> # The exception above was detected in native code outside the VM
> #
> # Java VM: Java HotSpot(TM) Server VM (1.4.2_08-b03 mixed mode)
> #
This is the problem I described caused by the Java nio(native input
output) code and is a bug in the JVM. Its a Java VM problem with a
native library that we have no control over.
Alastair
>
> thanks
>
> cheers
> alessandra
>
> On Mon, 27 Feb 2006 [log in to unmask] wrote:
>
> > Hi Alaistair,
> >
> >> What is the cause of the crash? Memory problems do not cause a crash,
> >> they will cause the server not to function correctly but that is another
> >> matter.
> >
> > if I knew it I wouldn't be asking :)
> >
> > The error in catalina.out is
> >
> > ============================================================================
> > An unexpected exception has been detected in native code outside the VM.
> > Unexpected Signal : 11 occurred at PC=0xB75CCF99
> > Function=pthread_kill+0x19
> > Library=/lib/tls/libpthread.so.0
> >
> > Current Java thread:
> > at sun.nio.ch.NativeThread.signal(Native Method)
> > at
> > sun.nio.ch.SocketChannelImpl.implCloseSelectableChannel(SocketChannelImpl.java:630)
> > - locked <0xa14899f8> (a java.lang.Object)
> > at
> > java.nio.channels.spi.AbstractSelectableChannel.implCloseChannel(AbstractSelectableChannel.java:202)
> > at
> > java.nio.channels.spi.AbstractInterruptibleChannel.close(AbstractInterruptibleChannel.java:97)
> > - locked <0xa14899b0> (a java.lang.Object)
> > at org.edg.info.InsertableInstance.close(InsertableInstance.java:566)
> > - locked <0xa1483438> (a java.util.HashMap)
> > - locked <0xa14831a8> (a org.edg.info.FastStreamProducerInstance)
> > at org.edg.info.InstanceTracker.remove(InstanceTracker.java:234)
> > - locked <0xa1108238> (a org.edg.info.InstanceTracker)
> > at
> > org.edg.info.RetentionPeriodTracker.run(RetentionPeriodTracker.java:111)
> >
> > [ ---- LIST OF SHARED LIBS ----- ]
> >
> > Heap at VM Abort:
> > Heap
> > def new generation total 21120K, used 5875K [0x9f150000, 0xa0830000,
> > 0xa0d10000)
> > eden space 18816K, 27% used [0x9f150000, 0x9f650cf0, 0xa03b0000)
> > from space 2304K, 32% used [0xa03b0000, 0xa046c150, 0xa05f0000)
> > to space 2304K, 0% used [0xa05f0000, 0xa05f0000, 0xa0830000)
> > tenured generation total 186872K, used 140040K [0xa0d10000, 0xac38e000,
> > 0xaeb50000)
> > the space 186872K, 74% used [0xa0d10000, 0xa95d2180, 0xa95d2200,
> > 0xac38e000)
> > compacting perm gen total 16384K, used 12412K [0xaeb50000, 0xafb50000,
> > 0xb2b50000)
> > the space 16384K, 75% used [0xaeb50000, 0xaf76f0a8, 0xaf76f200,
> > 0xafb50000)
> >
> > Local Time = Fri Feb 24 06:04:16 2006
> > Elapsed Time = 223132
> >
> > ===============================================================================
> >
> > To me it suggest memory problems but I'm not a java expert.
> >
> > thanks
> >
> > cheers
> > alessandra
> >
> >
> >> I've come across 2 problems with the tomcat server, one is an
> >> error on the boot of the server which causes a concurrent modification
> >> exception which is reported in /var/lib/tomcat5/logs/catalina.out. This
> >> is a problem with tomcat and we have no control over it - all you can do
> >> is restart and see if the error occurs. The other is a problem which
> >> occurs in native code outside of the VM and is most prevalent in dual
> >> processor machines. It is a problem which is caused by the Java nio code
> >> and is a bug in the JVM. It can help to use the threading libraries
> >> which were the default before kernel 2.4.20 this is done by adding in
> >> LD_ASSUME_KERNEL=2.4.19 to the tomcat5.conf this is done by yaim so
> >> should be present. However, this does not seem to be 100% effective as
> >> lcgmon01.gridpp.rl.ac.uk has been somewhat prone to the problem and this
> >> is a single processor machine. It also seems to be connected with
> >> problems associated with firewalls so if you have a consumer on your MON
> >> box that is trying to stream from a machine behind a firewall this can
> >> cause the crash and so tends to be on machines that are running an
> >> archiver(lcgmon01). It does not seem to affect every machine so its a
> >> difficult one to pin down and have a definitive answer to.
> >>
> >> Have you recently changed the machine that is used as the MON box? Could
> >> you try installing R-GMA on a different box? Check the log files and see
> >> if there is a problem with a firewalled connection.
> >>
> >> Alastair
> >>
> >>
> >>
> >>>
> >>> thanks
> >>>
> >>> cheers
> >>> alessandra
> >>
> >
> >
|