[
https://issues.apache.org/jira/browse/DERBY-5481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13135082#comment-13135082
]
Gray Watson edited comment on DERBY-5481 at 10/25/11 2:19 PM:
--------------------------------------------------------------
The end of the log file gives little help to me at least. It looks like it is
just dropping a database. This is probably junit cleanup @After each method
which drops any tables that were created in the test. Sounds like there is
some sort of race condition around the closing and possibly a thread still
using the database? I know there have been JVM finalizer race conditions
around file descriptors and the like in the past. But I don't see how this is
any of Derby's fault. Again, sorry for the possibly irrelevant time sink.
Tue Oct 25 10:15:32 EDT 2011 Thread[main,5,main] (XID = 164914), (SESSIONID =
25), (DATABASE = target/ormlitederby), (DRDAID = null), Begin compiling
prepared statement: DROP TABLE "FOOTABLE" :End prepared statement
Tue Oct 25 10:15:32 EDT 2011 Thread[main,5,main] (XID = 164914), (SESSIONID =
25), (DATABASE = target/ormlitederby), (DRDAID = null), End compiling prepared
statement: DROP TABLE "FOOTABLE" :End prepared statement
Tue Oct 25 10:15:32 EDT 2011 Thread[main,5,main] (XID = 164914), (SESSIONID =
25), (DATABASE = target/ormlitederby), (DRDAID = null), Committing
Tue Oct 25 10:15:32 EDT 2011 Thread[main,5,main] (XID = 164917), (SESSIONID =
25), (DATABASE = target/ormlitederby), (DRDAID = null), Executing prepared
statement: DROP TABLE "FOOTABLE" :End prepared statement
was (Author: graywatson):
The end of the log file gives little help to me at least. It looks like it
is just dropping a file. This is probably junit cleanup @After each method
which drops any tables that were created in the test. Sounds like there is
some sort of race condition around the closing and possibly a thread still
using the database? I know there have been JVM finalizer race conditions
around file descriptors and the like in the past. But I don't see how this is
any of Derby's fault. Again, sorry for the possibly irrelevant time sink.
Tue Oct 25 10:15:32 EDT 2011 Thread[main,5,main] (XID = 164914), (SESSIONID =
25), (DATABASE = target/ormlitederby), (DRDAID = null), Begin compiling
prepared statement: DROP TABLE "FOOTABLE" :End prepared statement
Tue Oct 25 10:15:32 EDT 2011 Thread[main,5,main] (XID = 164914), (SESSIONID =
25), (DATABASE = target/ormlitederby), (DRDAID = null), End compiling prepared
statement: DROP TABLE "FOOTABLE" :End prepared statement
Tue Oct 25 10:15:32 EDT 2011 Thread[main,5,main] (XID = 164914), (SESSIONID =
25), (DATABASE = target/ormlitederby), (DRDAID = null), Committing
Tue Oct 25 10:15:32 EDT 2011 Thread[main,5,main] (XID = 164917), (SESSIONID =
25), (DATABASE = target/ormlitederby), (DRDAID = null), Executing prepared
statement: DROP TABLE "FOOTABLE" :End prepared statement
> Unit tests fail on a derby closed iterator test with a "Invalid memory access
> of location"
> ------------------------------------------------------------------------------------------
>
> Key: DERBY-5481
> URL: https://issues.apache.org/jira/browse/DERBY-5481
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.8.1.2
> Environment: Eclipse 3.7.0 on Mac OSX 10.7.2
> Reporter: Gray Watson
> Priority: Minor
> Attachments: derby.log
>
>
> I'm the lead author of ORMLite, a smallish ORM project that supports Derby
> and some other JDBC and Android databases. I'm getting a reproducible memory
> fault during one of my Derby tests. I've just ignored the test for now in my
> code but I thought I'd report it.
> To check out the tree svn co
> http://ormlite.svn.sourceforge.net/svnroot/ormlite/ormliteTest/trunk
> You'll need maven. The DerbyEmbeddedBaseDaoImplTest is the one that fails.
> Not by itself unfortunately but running the com.j256.ormlite.dao package
> which is also testing some other database types causes it to fail every time
> for me. It's the testCloseInIterator() method defined in the test base class
> JdbcBaseDaoImplTest. This test closes the underlying database connection in
> the middle of an iterator loop to test exception handling.
> Sorry if this is just too obscure to be useful.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
