Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <3464688.1174238589253.JavaMail.jira@brutus>
Date: Sun, 18 Mar 2007 10:23:09 -0700 (PDT)
From: "Knut Anders Hatlen (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-2381) ParameterMappingTest fails due to
 ArrayIndexOutOfBoundsException  executing a procedure
In-Reply-To: <4487382.1172698971291.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-2381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12481962 ] 

Knut Anders Hatlen commented on DERBY-2381:
-------------------------------------------

I think there is a bug somewhere around client.net.Reply.getData()
and/or client.net.NetStatementReply.parseFDODTA(), but I don't know
the code well enough to say exactly what's wrong and how to fix
it. Anyway, here are my observations:

There is a call to Reply.getData() when ddmScalarLen_ is -1 before the
test fails (according to the code coverage report at
http://people.apache.org/~fuzzylogic/codecoverage/428586/, it's always
-1 when getData() is called). -1 means that the DDM length is unknown
because the DDM is streamed. getData() calls adjustLengths() which has
this line:

        ddmScalarLen_ -= length;

This will give ddmScalarLen_ a negative value different from -1 (-4),
which is an illegal state.

At a later point in the test, NetStatementReply.parseFDODTA() is
called, and ddmScalarLen_ still has the illegal value
-4. parseFDODTA() passes the value of ddmScalarLen_ to
ensureBLayerDataInBuffer() to ensure that there is enough data to read
from the buffer. Since the argument is negative, no more data is
fetched into the buffer.

Since parseFDODTA() has called ensureBLayerDataInBuffer(), it assumes
that it has enough data and uses "fast" methods to read the data. The
fast methods read data without calling ensureALayerDataInBuffer()
(presumably because the caller has already called it). Since no more
data was read when ensureBLayerDataInBuffer() was called,
parseFastSQLDTARDdata() and getFastData() suffer from an undetected
buffer underrun. The underrun causes false data to be read from the
buffer, and it makes pos_ (the position of the first available byte in
the buffer) greater than count_ (the position after the last available
byte in the buffer).

pos_ should never be greater than count_, and when Reply.shiftBuffer()
is called later, this will make the length argument to
System.arraycopy() negative, which is why we get an
ArrayIndexOutOfBoundsException.

> ParameterMappingTest fails due to ArrayIndexOutOfBoundsException  executing a procedure
> ---------------------------------------------------------------------------------------
>
>                 Key: DERBY-2381
>                 URL: https://issues.apache.org/jira/browse/DERBY-2381
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Client
>    Affects Versions: 10.3.0.0
>            Reporter: Kathey Marsden
>
> The test ParameterMappingTest fails due to a connection reset error during tearDown.  Commenting out the teardown actions I see that the real cause of the connection reset is an ArrayIndexOutOfBoundsException executing a callable statement.  I have not narrowed it down more than this.  Currently the test runs only for embedded. It should be reenabled for client once this bug is fixed.  Below is the stack trace:
> java.lang.ArrayIndexOutOfBoundsException
> 	at java.lang.System.arraycopy(Native Method)
> 	at org.apache.derby.client.net.Reply.shiftBuffer(Reply.java:107)
> 	at org.apache.derby.client.net.Reply.ensureSpaceInBufferForFill(Reply.java:153)
> 	at org.apache.derby.client.net.Reply.fill(Reply.java:165)
> 	at org.apache.derby.client.net.Reply.ensureALayerDataInBuffer(Reply.java(Compiled Code))
> 	at org.apache.derby.client.net.Reply.readDssHeader(Reply.java:317)
> 	at org.apache.derby.client.net.Reply.peekCodePoint(Reply.java:1008)
> 	at org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(NetStatementReply.java:324)
> 	at org.apache.derby.client.net.NetStatementReply.readExecuteCall(NetStatementReply.java:105)
> 	at org.apache.derby.client.net.StatementReply.readExecuteCall(StatementReply.java:75)
> 	at org.apache.derby.client.net.NetStatement.readExecuteCall_(NetStatement.java:176)
> 	at org.apache.derby.client.am.Statement.readExecuteCall(Statement.java:1464)
> 	at org.apache.derby.client.am.PreparedStatement.flowExecute(PreparedStatement.java:2151)
> 	at org.apache.derby.client.am.PreparedStatement.executeX(PreparedStatement.java:1571)
> 	at org.apache.derby.client.am.PreparedStatement.execute(PreparedStatement.java:1556)
> 	at org.apache.derbyTesting.functionTests.tests.jdbcapi.ParameterMappingTest.testParameterMapping(ParameterMappingTest.java:487)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
> 	at java.lang.reflect.Method.invoke(Method.java:391)
> 	at junit.framework.TestCase.runTest(TestCase.java:154)
> 	at junit.framework.TestCase.runBare(TestCase.java:127)
> 	at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76)
> 	at junit.framework.TestResult$1.protect(TestResult.java:106)
> 	at junit.framework.TestResult.runProtected(TestResult.java:124)
> 	at junit.framework.TestResult.run(TestResult.java:109)
> 	at junit.framework.TestCase.run(TestCase.java:118)
> 	at junit.framework.TestSuite.runTest(TestSuite.java:208)
> 	at junit.framework.TestSuite.run(TestSuite.java:203)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.framework.TestResult.runProtected(TestResult.java:124)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.framework.TestResult.runProtected(TestResult.java:124)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
> 	at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
> 	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

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