db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3316) Leak in client if ResultSet not closed
Date Thu, 17 Jan 2008 17:41:34 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12560009#action_12560009

Kathey Marsden commented on DERBY-3316:

For the adding it to the junit-all target option I think a few things have to happen for it
to be run as part of the nightlies.

1) Convert derbyStress.java to junit.
2) create a junit-lomem target and make it part of junit-all.
3) Fix junit-all so that it can run with the nightlies. DERBY-2045 + distribute ant to the
testing machines make nightly script changes etc.

I don't have time right now to pursue all of these, so am proposing we move derbyStress.java
back to derbyall for now until these goals can be accomplished so at least the nightlies are
testing the low memory scenarios.  Right now the test doesn't test much because it won't fail
even if there is a leak.  I think it was moved to JDBCHarnessJavaTest prematurely.  I'd like
to move it back to derbyall and open an issue to covert derbyStress outlining the issues.
 Does that sound ok? 

> Leak in client if ResultSet not closed
> --------------------------------------
>                 Key: DERBY-3316
>                 URL: https://issues.apache.org/jira/browse/DERBY-3316
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Client
>    Affects Versions:,,
>            Reporter: Kathey Marsden
>            Assignee: Kathey Marsden
>             Fix For:,
>         Attachments: derby-3316_diff.txt, derby-3316_diff2.txt, move_derbystress_to_derbyall_diff.txt,
> If I run the attached program RepeatStatement.java with 32M of heap,
> I will get an OutOfMemory error in the client.
> java -Xmx32M RepeatStatement
> Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
>        at org.apache.derby.client.am.Cursor.allocateCharBuffer(Cursor.java:1260)
>        at org.apache.derby.client.net.NetStatementReply.parseSQLDTARDarray(NetStatementReply.java:1356)
>        at org.apache.derby.client.net.NetStatementReply.parseQRYDSC(NetStatementReply.java:1207)
>        at org.apache.derby.client.net.NetStatementReply.parseOpenQuery(NetStatementReply.java:479)
>        at org.apache.derby.client.net.NetStatementReply.parseOPNQRYreply(NetStatementReply.java:223)
>        at org.apache.derby.client.net.NetStatementReply.readOpenQuery(NetStatementReply.java:64)
>        at org.apache.derby.client.net.StatementReply.readOpenQuery(StatementReply.java:50)
>        at org.apache.derby.client.net.NetStatement.readOpenQuery_(NetStatement.java:153)
>        at org.apache.derby.client.am.Statement.readOpenQuery(Statement.java:1396)
>        at org.apache.derby.client.am.Statement.flowExecute(Statement.java:2001)
>        at org.apache.derby.client.am.Statement.executeQueryX(Statement.java:421)
>        at org.apache.derby.client.am.Statement.executeQuery(Statement.java:406)
>        at RepeatStatement.testInsertAndSelect(RepeatStatement.java:31)
>        at RepeatStatement.main(RepeatStatement.java:10)
> If I close the ResultSet or Statement it does not leak. 
> This occurs on trunk and It does however not run out of memory on,
so appears to be a regression.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message