#38 StackOverflowError

open
nobody
None
5
2006-09-11
2006-09-11
Anders Wallgren
No

Any idea what could cause this to happen?

java.lang.StackOverflowError
at
sun.util.calendar.BaseCalendar.getCalendarDateFromFixedDate(BaseCalendar.java:416)
at
java.util.GregorianCalendar.computeFields(GregorianCalendar.java:2055)
at
java.util.GregorianCalendar.computeFields(GregorianCalendar.java:1970)
at java.util.Calendar.setTimeInMillis(Calendar.java:1066)
at
java.util.GregorianCalendar.<init>(GregorianCalendar.java:576)
at
java.util.GregorianCalendar.<init>(GregorianCalendar.java:562)
at com.mysql.jdbc.ResultSet.<init>(ResultSet.java:338)
at
com.mysql.jdbc.MysqlIO.buildResultSetWithRows(MysqlIO.java:1991)
at com.mysql.jdbc.MysqlIO.getResultSet(MysqlIO.java:447)
at
com.mysql.jdbc.MysqlIO.readResultsForQueryOrUpdate(MysqlIO.java:1970)
at
com.mysql.jdbc.MysqlIO.readAllResults(MysqlIO.java:1387)
at
com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1727)
at com.mysql.jdbc.Connection.execSQL(Connection.java:3118)
at com.mysql.jdbc.Connection.execSQL(Connection.java:3047)
at
com.mysql.jdbc.Statement.executeQuery(Statement.java:1166)
at
com.mysql.jdbc.DatabaseMetaData$9.forEach(DatabaseMetaData.java:4355)
at
com.mysql.jdbc.DatabaseMetaData$IterateBlock.doForAll(DatabaseMetaData.java:76)
at
com.mysql.jdbc.DatabaseMetaData.getTables(DatabaseMetaData.java:4342)
at
com.mchange.v2.c3p0.impl.DefaultConnectionTester.activeCheckConnection(DefaultConnectionTester.java:104)
at
com.mchange.v2.c3p0.impl.DefaultConnectionTester.statusOnException(DefaultConnectionTester.java:77)
at
com.mchange.v2.c3p0.impl.DefaultConnectionTester.statusOnException(DefaultConnectionTester.java:56)
at
com.mchange.v2.c3p0.impl.NewPooledConnection.handleThrowable(NewPooledConnection.java:355)
at
com.mchange.v2.c3p0.impl.NewProxyStatement.executeQuery(NewProxyStatement.java:52)
at
com.mchange.v2.c3p0.impl.DefaultConnectionTester.activeCheckConnection(DefaultConnectionTester.java:139)
at
com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool$1PooledConnectionResourcePoolManager.testPooledConnection(C3P0PooledConnectionPool.java:239)
at
com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool$1PooledConnectionResourcePoolManager.refurbishResourceOnCheckout(C3P0PooledConnectionPool.java:182)
at
com.mchange.v2.resourcepool.BasicResourcePool.attemptRefurbishResourceOnCheckout(BasicResourcePool.java:1167)
at
com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:324)
at
com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:328)
at
com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:328)
at
com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:328)
at
com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:328)
at
com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:328)
at
com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:328)
at
com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:328)
at
com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:328)
at
com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:328)
at
com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:328)
at
com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:328)
at
com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:328)
at
com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:328)
at
com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:328)
at
com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:328)
at
com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:328)
at
com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:328)
at
com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:328)
at
com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:328)
at
com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:328)
...and so on...

Discussion

  • Steve Waldman
    Steve Waldman
    2006-09-12

    Logged In: YES
    user_id=175530

    Anders -- It's pretty clear what's going on: 1) a client is
    trying to checkout a Connection; 2) testConnectionOnCheckout
    is set to true; 3) c3p0's checkoutResource() method tries to
    supply a Connection, but the Connection fails the test; 4)
    checkoutResource() removes the damaged Connection from the
    pool and calls itself recursively; 5) this happens many,
    many times, with the recursive calls to checkResource()
    eventually getting close to the JVM's maximum stack size; 6)
    an attempted Connection test blows the stack.

    The possibility of a blown stack on repeated checkout
    failure is a weakness noted in c3p0's source. But this is
    the first report of the problem actually having been
    observed "in the wild".

    In practical terms, you'll want to understand why your
    Connections repeatedly are failing checkout tests. The
    easiest way to do this is to turn on DEBUG- (log4j) or FINE-
    (jdk14 api) level logging for logger
    "com.mchange.v2.c3p0.impl.DefaultConnectionTester".

    For my part, since this hypothetical failure has now been
    observed, it'd probably be a good idea to modify the pool to
    fail more gracefully in this kind of situation...

    Thank you for the useful report.

     
  • Steve Waldman
    Steve Waldman
    2007-01-02

    Logged In: YES
    user_id=175530
    Originator: NO

    Note: I'm putting off (until 0.9.2) a more graceful failure when Connection checkout continuously fails, because the StackOverflow seems to be very rare in practice, and I don't want to mess with the core BasicResourcePool code this late in 0.9.1's development cycle.

     
  • Logged In: YES
    user_id=2116858
    Originator: NO

    I also see the same behavior in BasicResourcePool in v0.9.1. The connections are fine. But, I think it has a conflict during checkout because the connection is in idleCheck and then it goes into a loop.

    Here is the stack trace:

    2008-06-12 21:51:45,900 [TP-Processor55] ERROR com.citrix.workplace.jpa.Trans
    actionViewFilter - emp_1115@cust4.com:41000-Unknown generic error.
    java.lang.StackOverflowError
    at com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResour
    ce(BasicResourcePool.java:494)
    at com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResour
    ce(BasicResourcePool.java:495)
    at com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResour
    ce(BasicResourcePool.java:495)
    at com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResour
    ce(BasicResourcePool.java:495)
    at com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResour
    ce(BasicResourcePool.java:495)
    at com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResour
    ce(BasicResourcePool.java:495)
    at com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResour
    ce(BasicResourcePool.java:495)
    at com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResour
    ce(BasicResourcePool.java:495)
    at com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResour
    ce(BasicResourcePool.java:495)
    at com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResour
    at com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResour
    ce(BasicResourcePool.java:495)
    at com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResour
    ce(BasicResourcePool.java:495)
    at com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResour
    ce(BasicResourcePool.java:495)
    at com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResour
    ce(BasicResourcePool.java:495)
    at com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResour
    ce(BasicResourcePool.java:495)
    at com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResour
    ce(BasicResourcePool.java:495)
    at com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResour
    ce(BasicResourcePool.java:495)
    at com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResour
    ce(BasicResourcePool.java:495)
    at com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResour
    ce(BasicResourcePool.java:495)
    at com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResour
    ce(BasicResourcePool.java:495)
    at com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResour
    ce(BasicResourcePool.java:495)
    ..................................................
    ............................. (several statements in stack trace for line 495) and then these lines.....

    at com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(Bas
    icResourcePool.java:388)
    at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool.checkoutPooledCo
    nnection(C3P0PooledConnectionPool.java:486)
    at com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource.getConnectio
    n(AbstractPoolBackedDataSource.java:128)

     
  • Logged In: YES
    user_id=597579
    Originator: YES

    >> For my part, since this hypothetical failure has now been
    >> observed, it'd probably be a good idea to modify the pool to
    >> fail more gracefully in this kind of situation...

    Still seeing this problem when there are database hickups. It's been nearly two years since the report was filed -- any progress on this issue? Should I dive into the code and provide a fix myself?