c3p0:JDBC DataSources/Resource Pools

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