jvm crash

[nikil shar]

ok i must have done something horribly wrong since the jvm crashed. belows is my code, i am trying to run 2 threads to select from oracle databases and update table column to flag a success after the select is complete

public class Test extends Thread {

private Statement CompactStmt = null
private ResultSet rs=null;

public void run () {
   String threadName = Thread.currentThread().getName();

 try {
   rs = CompactStmt.executeQuery("select * from table ...");

   while (rs.next()){
                //do some data logic with the data

          updateTable("SUCCESS");
    }

  } catch (SQLException e) {
     System.out.println(e.getMesage());
  }

}


}

and the error report i got is

#
# An unexpected error has been detected by Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0xff381a6c, pid=8578, tid=140
#
# Java VM: Java HotSpot(TM) Server VM (10.0-b23 mixed mode solaris-sparc)
# Problematic frame:
# C  [libc_psr.so.1+0x1a6c]  memcpy+0x10b0
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

---------------  T H R E A D  ---------------

Current thread (0x00b20400):  JavaThread "Thread0 " [_thread_in_native, id=140, stack(0xaee80000,0xaef00000)]

siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0xff3ac000

Registers:
 O0=0x00d9c640 O1=0xff3adc04 O2=0x0000005b O3=0x00000000
 O4=0xff3ac000 O5=0x00001c40 O6=0xaeefda88 O7=0xfe3cd14c
 G1=0x00d9b468 G2=0x00a25dec G3=0x00000000 G4=0xfe7c0000
 G5=0x00000004 G6=0x00000000 G7=0xfe045200 Y=0x00000000
 PC=0xff381a6c nPC=0xff381a70


Top of Stack: (sp=0xaeefda88)
0xaeefda88:   ff3aadbe 00000008 00000000 00000000
0xaeefda98:   00000000 f7f80000 ffffffff 00000000
0xaeefdaa8:   08080000 00000000 00b209f0 00007361
0xaeefdab8:   00002e73 00006c63 aeefdae8 fe3c2354
0xaeefdac8:   00000000 00000000 00000000 00000000
0xaeefdad8:   00000000 00000000 00000000 00000000
0xaeefdae8:   0000002f c2a57d83 00000035 009891ac
0xaeefdaf8:   c2a57d94 00988f30 0000027c 0000009f

Instructions: (pc=0xff381a6c)
0xff381a5c:   10 80 00 1b 81 43 e0 40 c1 9b 1e 00 98 03 20 40

0xff381a6c:   e1 9b 1e 00 a3 b0 09 02 a7 b0 89 04 ab b1 09 06

Stack: [0xaee80000,0xaef00000],  sp=0xaeefda88,  free space=502k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libc_psr.so.1+0x1a6c]  memcpy+0x10b0
C  [libzip.so+0x235c]  ZIP_GetEntry+0xe4
C  [libzip.so+0x27dc]  Java_java_util_zip_ZipFile_getEntry+0xc4
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter
v  ~BufferBlob::StubRoutines (1)
V  [libjvm.so+0x133454]
V  [libjvm.so+0x193264]
C  [libjava.so+0xf58c]  Java_java_security_AccessController_doPrivileged__Ljava_security_PrivilegedExceptionAction_2Ljava_security_Acces
sControlContext_2+0x1c
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter
v  ~BufferBlob::StubRoutines (1)
V  [libjvm.so+0x133454]
V  [libjvm.so+0x1b9c80]
V  [libjvm.so+0x1515bc]
V  [libjvm.so+0x11a88c]
V  [libjvm.so+0x12a380]
V  [libjvm.so+0x70720c]
V  [libjvm.so+0xdddf8]
V  [libjvm.so+0x148878]
v  ~BufferBlob::Interpreter
v  ~BufferBlob::StubRoutines (1)
V  [libjvm.so+0x133454]
V  [libjvm.so+0x47cb78]
V  [libjvm.so+0x1d3ce8]
V  [libjvm.so+0x1e7354]
V  [libjvm.so+0x71767c]
V  [libjvm.so+0x66d150]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter
v  ~BufferBlob::StubRoutines (1)
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter
v  ~BufferBlob::Interpreter
v  ~BufferBlob::StubRoutines (1)
v  ~BufferBlob::Interpreter
v  ~BufferBlob::StubRoutines (1)

---------------  P R O C E S S  ---------------

Java Threads: ( => current thread )
=>0x00b20400 JavaThread "Thread0" [_thread_in_native, id=140, stack(0xaee80000,0xaef00000)]
  0x00cedc00 JavaThread "Thread1" [_thread_in_native, id=139, stack(0xaef80000,0xaf000000)]
  0x0096d800 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=137, stack(0xaf180000,0xaf200000)]
  0x0096ac00 JavaThread "CompilerThread1" daemon [_thread_blocked, id=136, stack(0xaf280000,0xaf300000)]
  0x00968800 JavaThread "CompilerThread0" daemon [_thread_in_native, id=135, stack(0xaf380000,0xaf400000)]
  0x00967800 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=134, stack(0xaf480000,0xaf500000)]
  0x0094a000 JavaThread "Finalizer" daemon [_thread_blocked, id=133, stack(0xaf580000,0xaf600000)]
  0x00949000 JavaThread "Reference Handler" daemon [_thread_blocked, id=132, stack(0xaf680000,0xaf700000)]
  0x00032c00 JavaThread "main" [_thread_blocked, id=2, stack(0xfe480000,0xfe500000)]

Other Threads:
  0x00946000 VMThread [stack: 0xaf780000,0xaf800000] [id=131]
  0x0096f000 WatcherThread [stack: 0xaf080000,0xaf100000] [id=138]

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

Heap
 PSYoungGen      total 78848K, used 12204K [0xe6400000, 0xebc00000, 0xfbc00000)
  eden space 67584K, 18% used [0xe6400000,0xe6feb0f8,0xea600000)
  from space 11264K, 0% used [0xeb100000,0xeb100000,0xebc00000)
  to   space 11264K, 0% used [0xea600000,0xea600000,0xeb100000)
 PSOldGen        total 176128K, used 0K [0xbb800000, 0xc6400000, 0xe6400000)
  object space 176128K, 0% used [0xbb800000,0xbb800000,0xc6400000)
 PSPermGen       total 16384K, used 6817K [0xb7800000, 0xb8800000, 0xbb800000)
  object space 16384K, 41% used [0xb7800000,0xb7ea85a8,0xb8800000)


T
Launcher Type: SUN_STANDARD


Signal Handlers:
SIGSEGV: [libjvm.so+0x767c10], sa_mask[0]=0xffbffeff, sa_flags=0x0000000c
SIGBUS: [libjvm.so+0x767c10], sa_mask[0]=0xffbffeff, sa_flags=0x0000000c
SIGFPE: [libjvm.so+0x1a5544], sa_mask[0]=0xffbffeff, sa_flags=0x0000000c
SIGPIPE: [libjvm.so+0x1a5544], sa_mask[0]=0xffbffeff, sa_flags=0x0000000c
SIGXFSZ: [libjvm.so+0x1a5544], sa_mask[0]=0xffbffeff, sa_flags=0x0000000c
SIGILL: [libjvm.so+0x1a5544], sa_mask[0]=0xffbffeff, sa_flags=0x0000000c
SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGUSR2: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGQUIT: [libjvm.so+0x66f344], sa_mask[0]=0xffbffeff, sa_flags=0x00000004
SIGHUP: [libjvm.so+0x66f344], sa_mask[0]=0xffbffeff, sa_flags=0x00000004
SIGINT: [libjvm.so+0x66f344], sa_mask[0]=0xffbffeff, sa_flags=0x00000004
SIGTERM: [libjvm.so+0x66f344], sa_mask[0]=0xffbffeff, sa_flags=0x00000004
SIG39: [libjvm.so+0x67294c], sa_mask[0]=0x00000000, sa_flags=0x00000008
SIG40: [libjvm.so+0x1a5544], sa_mask[0]=0xffbffeff, sa_flags=0x0000000c


---------------  S Y S T E M  ---------------

OS:                   Oracle Solaris 10 9/10 s10s_u9wos_14a SPARC
     Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved.
                            Assembled 11 August 2010

uname:SunOS 5.10 Generic_142909-17 sun4v  (T2 libthread)
rlimit: STACK 8192k, CORE infinity, NOFILE 65536, AS infinity
load average:3.70 3.33 3.10

CPU:total 128 has_v8, has_v9, has_vis1, has_vis2, is_ultra3, is_sun4v, is_niagara1

Memory: 8k page, physical 16777216k(12912472k free)

vm_info: Java HotSpot(TM) Server VM (10.0-b23) for solaris-sparc JRE (1.6.0_07-b06), built on Jun 10 2008 01:39:38 by "" with Workshop 5
.8

time: Thu Feb 17 10:56:13 2011
elapsed time: 5799 seconds

the error doesnt point to any line in the code so am not sure what is causing the issue. there is a lot of data being returned from the database (approx 1million rows) but i dont see any memory issues since the error report shows there is enough memory available.

i dont think its the code since the same code used to work before.

can someone suggest what the issue could be ??

[Ernest Friedman-Hill]

No, it's not your code. Whenever the JVM crashes, it's the fault of the JVM or some native code that's being linked in; by definition Java code can't make the JVM crash.

I can see from the below that you're running 1.6.0p7; the current version is 1.6.0p23 (or 24?) The first thing I'd try is simply to bring your JVM up to date; the bug that causes the crash is likely to have been fixed in a later revision.

[nikil shar]

Ernest Friedman-Hill wrote:No, it's not your code. Whenever the JVM crashes, it's the fault of the JVM or some native code that's being linked in; by definition Java code can't make the JVM crash.

I can see from the below that you're running 1.6.0p7; the current version is 1.6.0p23 (or 24?) The first thing I'd try is simply to bring your JVM up to date; the bug that causes the crash is likely to have been fixed in a later revision.

thanks for the reply. is there a way to confirm by looking at the error message that an upgrade would fix this issue ?? I will need a good case before anyone would let me upgrade the jvm.

thanks again.

[Henry Wong]

And since this has little to do with "threads and synchronization", moving this to java in general.

Henry

[Henry Wong]

nikil shar wrote:
thanks for the reply. is there a way to confirm by looking at the error message that an upgrade would fix this issue ?? I will need a good case before anyone would let me upgrade the jvm.

How about just upgrading the test environment? Or just one of the test machines? If it works, you will have a good case to upgrade it in QA, and then (after testing) in production.

Henry

[nikil shar]

Henry Wong wrote:

nikil shar wrote:
thanks for the reply. is there a way to confirm by looking at the error message that an upgrade would fix this issue ?? I will need a good case before anyone would let me upgrade the jvm.

How about just upgrading the test environment? Or just one of the test machines? If it works, you will have a good case to upgrade it in QA, and then (after testing) in production.

Henry

thanks for the reply. This crashing issue is very random. We have a totally seperate environment with the same jvm and the same code and i havent seen it crash in that environment . my problem is that i dont know how to interpret the error message thrown by the jvm crash. any clues as to how to go about interpreting the long error message ??

and thanks for moving this thread to an appropriate forum.

[Henry Wong]

nikil shar wrote:
thanks for the reply. This crashing issue is very random. We have a totally seperate environment with the same jvm and the same code and i havent seen it crash in that environment . my problem is that i dont know how to interpret the error message thrown by the jvm crash. any clues as to how to go about interpreting the long error message ??

Well, without source code, you can only do so much. From the dump, it's a segmentation violation (accessing memory that doesn't exist -- or without the correct permissions). The operation was a memcpy (memory copy) and it was part of the libc_psr library. All the other information are used to isolate the code, and the state at the time that it happened.

With the source code, a JVM engineer at Sun/Oracle can use this output hunt down the issue (having the JVM dump core would be even better).

Henry