[c3p0-users] jvm crash while loading
Status: Beta
Brought to you by:
swaldman
|
From: Xu-Feng M. <m9...@gm...> - 2011-08-05 08:57:18
|
Hi,
We're using c3p0-0.9.1.2, but run into a jvm crash. The environment is,
CentOS5.4
Linux testllap07 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64
x86_64 x86_64 GNU/Linux
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode)
The c3p0 configuration is like
<comment>com.snda.llap.indexservice.keybase.database</comment>
<entry key="initialPoolSize">10</entry>
<entry key="acquireIncrement">3</entry>
<entry key="minPoolSize">10</entry>
<entry key="maxStatements">0</entry>
<entry key="maxStatementsPerConnection">0</entry>
<entry key="maxIdleTime">25200</entry>
<entry key="driverClass">com.mysql.jdbc.Driver</entry>
<entry key="jdbcUrl">jdbc:mysql://127.0.0.1:3310</entry>
<entry key="user">root</entry>
<entry key="password">llap_keybase_mysql</entry>
The jvm crash we've got is like
======
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x000000359067c52b, pid=2708, tid=1112025408
#
# JRE version: 6.0_20-b02
# Java VM: Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode
linux-amd64 )
# Problematic frame:
# C [libc.so.6+0x7c52b] memcpy+0x2eb
#
# 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.
#
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
code)
C [libc.so.6+0x7c52b] memcpy+0x2eb
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j java.util.zip.ZipFile.getEntry(JLjava/lang/String;Z)J+0
j
java.util.zip.ZipFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry;+31
j
java.util.jar.JarFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry;+2
j
java.util.jar.JarFile.getJarEntry(Ljava/lang/String;)Ljava/util/jar/JarEntry;+2
j
sun.misc.URLClassPath$JarLoader.getResource(Ljava/lang/String;Z)Lsun/misc/Resource;+48
j
sun.misc.URLClassPath.getResource(Ljava/lang/String;Z)Lsun/misc/Resource;+53
j java.net.URLClassLoader$1.run()Ljava/lang/Object;+26
v ~StubRoutines::call_stub
j
java.security.AccessController.doPrivileged(Ljava/security/PrivilegedExceptionAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;+0
j java.net.URLClassLoader.findClass(Ljava/lang/String;)Ljava/lang/Class;+13
j java.lang.ClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+47
j
sun.misc.Launcher$AppClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+41
j java.lang.ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class;+3
v ~StubRoutines::call_stub
j
com.mchange.v2.resourcepool.BasicResourcePool.destroyResource(Ljava/lang/Object;Z)V+0
j
com.mchange.v2.resourcepool.BasicResourcePool.removeResource(Ljava/lang/Object;Z)V+182
j
com.mchange.v2.resourcepool.BasicResourcePool.removeResource(Ljava/lang/Object;)V+3
j com.mchange.v2.resourcepool.BasicResourcePool.cullExpired()V+205
j
com.mchange.v2.resourcepool.BasicResourcePool.access$1900(Lcom/mchange/v2/resourcepool/BasicResourcePool;)V+1
j com.mchange.v2.resourcepool.BasicResourcePool$CullTask.run()V+78
j java.util.TimerThread.mainLoop()V+221
j java.util.TimerThread.run()V+1
v ~StubRoutines::call_stub
======
It looks like when the pool is trying to destory a resouce due to
maxIdleTime reaches, the jvm is going to load class
BasicResourcePool$1$DestroyResourceTask(not quite sure about the class
name), the classloading cause a SIGSEGV
inside the native method of
java.util.zip.ZipFile.getEntry(JLjava/lang/String;Z).
We wonder does any one see the same issue before? We're set maxIdleTime to
25200, which seems a bit
larger. Any comment is appreciated.
Thanks and regards,
Mao Xu-Feng
|