[
https://issues.apache.org/jira/browse/DERBY-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615592#action_12615592
]
Knut Anders Hatlen commented on DERBY-3786:
-------------------------------------------
Tried the repro with JDK 1.4 to see if we get the same behaviour with the old
cache manager (Clock) as with the new one (ConcurrentCache). I then got this
assert failure:
java.sql.SQLException: Java exception: 'ASSERT FAILED:
org.apache.derby.shared.common.sanity.AssertFailure'.
at
org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:87)
at org.apache.derby.impl.jdbc.Util.javaException(Util.java:244)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:403)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:346)
at
org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2192)
at
org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:81)
at
org.apache.derby.impl.jdbc.EmbedPreparedStatement.<init>(EmbedPreparedStatement.java:146)
at
org.apache.derby.impl.jdbc.EmbedPreparedStatement20.<init>(EmbedPreparedStatement20.java:82)
at
org.apache.derby.impl.jdbc.EmbedPreparedStatement30.<init>(EmbedPreparedStatement30.java:63)
at
org.apache.derby.jdbc.Driver30.newEmbedPreparedStatement(Driver30.java:99)
at
org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(EmbedConnection.java:1533)
at
org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(EmbedConnection.java:1361)
at d3786$1.run_(d3786.java:26)
at d3786$1.run(d3786.java:15)
at java.lang.Thread.run(Thread.java:534)
Caused by: org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED
at
org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:98)
at
org.apache.derby.impl.services.cache.CachedItem.unkeep(CachedItem.java:144)
at org.apache.derby.impl.services.cache.Clock.remove(Clock.java:603)
at
org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.removeStatement(GenericLanguageConnectionContext.java:898)
at
org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:516)
at
org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:88)
at
org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java:794)
at
org.apache.derby.impl.jdbc.EmbedPreparedStatement.<init>(EmbedPreparedStatement.java:128)
... 8 more
The failing assert is this one in CachedItem.unkeep():
if (SanityManager.DEBUG) {
SanityManager.ASSERT(keepCount >= 0);
}
> Assert failure in CacheEntry.unkeepForRemove when running stress.multi
> ----------------------------------------------------------------------
>
> Key: DERBY-3786
> URL: https://issues.apache.org/jira/browse/DERBY-3786
> Project: Derby
> Issue Type: Bug
> Components: Services
> Affects Versions: 10.5.0.0
> Environment: 32 hardware execution threads
> Reporter: Kristian Waagan
> Priority: Minor
> Attachments: d3786.java
>
>
> When running stress.multi on a machine with 32 hardware execution threads, I
> observed the following assert failure in two independent runs:
> -----
> 2008-07-18 02:15:14.415 GMT Thread[Thread-8,5,workers] (XID = 94699),
> (SESSIONID = 16923), (DATABASE = mydb), (DRDAID = null), Failed Statement is:
> insert into a values (1)
> org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED
> at
> org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:98)
> at
> org.apache.derby.impl.services.cache.CacheEntry.unkeepForRemove(CacheEntry.java:217)
> at
> org.apache.derby.impl.services.cache.ConcurrentCache.remove(ConcurrentCache.java:446)
> at
> org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.removeStatement(GenericLanguageConnectionContext.java:898)
> at
> org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:516)
> at
> org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:88)
> at
> org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java:794)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:606)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:555)
> at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:329)
> at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:508)
> at
> org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(utilMain.java:350)
> at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:248)
> at
> org.apache.derby.impl.tools.ij.mtTestCase.runMe(mtTestCase.java:246)
> at org.apache.derby.impl.tools.ij.mtTester.run(mtTester.java:91)
> at java.lang.Thread.run(Thread.java:619)
> Cleanup action completed
> -----
> In stress.log:
> -----
> Tester8: insert2 Fri Jul 18 04:15:12 CEST 2008
> Tester6: TERMINATING due to unexpected error:
> FatalException: XJ001: Java exception: 'ASSERT FAILED:
> org.apache.derby.shared.common.sanity.AssertFailure'.
> Tester1: SELECT2 Fri Jul 18 04:15:13 CEST 2008
> Tester8: stopping on request after 820 iterations
> Tester10: stopping on request after 859 iterations
> Tester1: stopping on request after 847 iterations
> Tester7: TERMINATING due to unexpected error:
> FatalException: XJ001: Java exception: 'ASSERT FAILED:
> org.apache.derby.shared.common.sanity.AssertFailure'.
> Tester9: stopping on request after 722 iterations
> Tester3: stopping on request after 880 iterations
> Tester5: stopping on request after 858 iterations
> Tester4: stopping on request after 839 iterations
> WARNING: testers didn't die willingly, so I'm going to kill 'em.
> This may result in connection resources that aren't cleaned up
> (e.g. you may see problems in the final script run with deadlocks).
> -----
> A few runs on a similar but slightly slower machine didn't experience the
> same failure, so the bug is likely timing dependent.
> I'll perform some more runs and see how hard it is to reproduce.
> I haven't investigated what will happen in an insane build.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
