db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A B (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-1329) ASSERT failure/IndexOutOfBoundsException with correlated subquery for UPDATE ... SET ... WHERE CURRENT OF ... statement.
Date Tue, 16 May 2006 18:26:06 GMT
     [ http://issues.apache.org/jira/browse/DERBY-1329?page=all ]

A B updated DERBY-1329:

    Attachment: d1329.java

Attaching a simple repro program for this issue.  Default is to run against the Derby Client,
so you'll have to start the server on 1527 first.  

> java d1329

To run against embedded:

> java d1329 embedded

To run against JCC, start server on 1527 then:

> java d1329 jcc

> ASSERT failure/IndexOutOfBoundsException with correlated subquery for UPDATE ... SET
... WHERE CURRENT OF ... statement.
> ------------------------------------------------------------------------------------------------------------------------
>          Key: DERBY-1329
>          URL: http://issues.apache.org/jira/browse/DERBY-1329
>      Project: Derby
>         Type: Bug

>   Components: SQL
>     Versions:,,,,,,,,,,
>     Reporter: A B
>     Assignee: A B
>     Priority: Minor
>      Fix For:,
>  Attachments: d1329.java
> If in a statement of the form "UPDATE ... SET ... WHERE CURRENT OF ..." the SET clause
includes a correlated subquery that has a predicate referencing the table that is being updated,
Derby will fail with an ASSERT failure in sane mode and an IndexOutOfBounds exception in insane
> For example, if we have a cursor CUR1 for the results of a SELECT query on BASICTABLE1,
and then we try to execute the following update statement:
> update BASICTABLE1 set C3 = (SELECT CC3 FROM
> where current of CUR1
> the result in SANE mode will be:
> org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED tableNumber is expected
to be non-negative.
> and in INSANE mode will be:
> java.lang.IndexOutOfBoundsException: bitIndex < 0: -1
> The failure occurs during preprocessing of the subquery node when Derby is trying to
"categorize" a predicate to see if it is pushable.  The exact code is in ColumnReference.categorize():
>   public boolean categorize(JBitSet referencedTabs, boolean simplePredsOnly)
>   {
>     if (SanityManager.DEBUG)
>       SanityManager.ASSERT(tableNumber >= 0,
>          "tableNumber is expected to be non-negative");
>     referencedTabs.set(tableNumber);
>     return ( ! replacesAggregate ) &&
>         ( (source.getExpression() instanceof ColumnReference) ||
>         (source.getExpression() instanceof VirtualColumnNode) ||
>         (source.getExpression() instanceof ConstantNode));
>   }
> We get to this code for a ColumnReference who's tableNumber is -1, which means that,
in sane mode, the assert will fire; in insane mode, we'll call "referencedTabs.set()" passing
in a -1, which leads to the IndexOutOfBoundsException.
> This failure occurs in embedded and with both clients, and occurs in 10.0, 10.1, and
the 10.2 trunk.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message