You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Knut Anders Hatlen (JIRA)" <ji...@apache.org> on 2008/08/20 22:18:47 UTC
[jira] Updated: (DERBY-3786) Assert failure in
CacheEntry.unkeepForRemove when running stress.multi
[ https://issues.apache.org/jira/browse/DERBY-3786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-3786:
--------------------------------------
Attachment: remove_v2.diff
Here's a new version of the patch with comments added. Derbyall and suites.All still run cleanly.
> 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
> Assignee: Knut Anders Hatlen
> Priority: Minor
> Attachments: d3786.java, remove.diff, remove_v2.diff
>
>
> 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.