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 "A B (JIRA)" <de...@db.apache.org> on 2006/10/06 20:47:21 UTC

[jira] Created: (DERBY-1939) ERROR XSDA7 while executing query that spills to BackingStoreHashTable

ERROR XSDA7 while executing query that spills to BackingStoreHashTable
----------------------------------------------------------------------

                 Key: DERBY-1939
                 URL: http://issues.apache.org/jira/browse/DERBY-1939
             Project: Derby
          Issue Type: Bug
          Components: Store
    Affects Versions: 10.1.3.1, 10.1.3.0, 10.1.3.2
            Reporter: A B


I have a database with a large query that's failing in Derby 10.1 with:

  ERROR XSDA7: Restore of a serializable or SQLData object of class , attempted to read more data than was
  originally stored

The error only occurs if I use a PreparedStatement for the query and if I specify a parameter marker for one particular equality operand.  If I replace the parameter with an actual value, the query runs without error.

I was eventually able to come up with a standalone repro that uses nonsense tables and a nonsense query but still demonstrates the problem.  That said, the error does *not* occur in Derby 10.2 or main, so it has apparently been fixed in those codelines.

I did some investigating and was eventually able to track the fix down to svn commit # 389202 (DERBY-690).  Before that checkin the query fails against 10.2, but after that it runs without error.  It turns out that there's one uncommented change in svn 389202 that seems to have fixed the problem, namely:

Index: java/engine/org/apache/derby/impl/store/access/heap/HeapRowLocation.java
===================================================================
--- java/engine/org/apache/derby/impl/store/access/heap/HeapRowLocation.java	(revision 389043)
+++ java/engine/org/apache/derby/impl/store/access/heap/HeapRowLocation.java	(working copy)
@@ -104,7 +104,7 @@
    }
 
     public DataValueDescriptor getNewNull() {
-        return null;
+        return new HeapRowLocation();
    }
 
To confirm I undid this one line change in the 10.3 codeline and then the query started failing there.  Similarly, after I made this one-line change in the latest 10.1 codeline, the query started running successfully.  So apparently this is the fix to the problem...though I don't really know why...?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] Resolved: (DERBY-1939) ERROR XSDA7 while executing query that spills to BackingStoreHashTable

Posted by "Mike Matrigali (JIRA)" <de...@db.apache.org>.
     [ http://issues.apache.org/jira/browse/DERBY-1939?page=all ]

Mike Matrigali resolved DERBY-1939.
-----------------------------------

    Fix Version/s: 10.1.3.2
       Resolution: Fixed

committed fix to 10.1, also checked in new test for this problem.  The problem is already fixed in 10.2.  

Fixes HeapRowLocation.getNewNull() to return actual null object, this
functionality is used by the hash overflow to disk code.  Without this
change the HeapRowLocation is correctly written out to the StoredPage,
but on read the overflow code passes a null template which causes the
wrong code to read the data back into the object.

> ERROR XSDA7 while executing query that spills to BackingStoreHashTable
> ----------------------------------------------------------------------
>
>                 Key: DERBY-1939
>                 URL: http://issues.apache.org/jira/browse/DERBY-1939
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.1.3.1, 10.1.3.2
>            Reporter: A B
>         Assigned To: Mike Matrigali
>             Fix For: 10.1.3.2
>
>         Attachments: d1939.java, d1939_log.txt
>
>
> I have a database with a large query that's failing in Derby 10.1 with:
>   ERROR XSDA7: Restore of a serializable or SQLData object of class , attempted to read more data than was
>   originally stored
> The error only occurs if I use a PreparedStatement for the query and if I specify a parameter marker for one particular equality operand.  If I replace the parameter with an actual value, the query runs without error.
> I was eventually able to come up with a standalone repro that uses nonsense tables and a nonsense query but still demonstrates the problem.  That said, the error does *not* occur in Derby 10.2 or main, so it has apparently been fixed in those codelines.
> I did some investigating and was eventually able to track the fix down to svn commit # 389202 (DERBY-690).  Before that checkin the query fails against 10.2, but after that it runs without error.  It turns out that there's one uncommented change in svn 389202 that seems to have fixed the problem, namely:
> Index: java/engine/org/apache/derby/impl/store/access/heap/HeapRowLocation.java
> ===================================================================
> --- java/engine/org/apache/derby/impl/store/access/heap/HeapRowLocation.java	(revision 389043)
> +++ java/engine/org/apache/derby/impl/store/access/heap/HeapRowLocation.java	(working copy)
> @@ -104,7 +104,7 @@
>     }
>  
>      public DataValueDescriptor getNewNull() {
> -        return null;
> +        return new HeapRowLocation();
>     }
>  
> To confirm I undid this one line change in the 10.3 codeline and then the query started failing there.  Similarly, after I made this one-line change in the latest 10.1 codeline, the query started running successfully.  So apparently this is the fix to the problem...though I don't really know why...?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] Updated: (DERBY-1939) ERROR XSDA7 while executing query that spills to BackingStoreHashTable

Posted by "A B (JIRA)" <de...@db.apache.org>.
     [ http://issues.apache.org/jira/browse/DERBY-1939?page=all ]

A B updated DERBY-1939:
-----------------------

    Attachment: d1939.java
                d1939_log.txt

Attaching a repro for the problem described in this issue.  To run:

// First load the data.
> java d1939 load

// Then run the query to see the failure.
> java d1939

Remember: Only occurs against 10.1.

Also attaching the derby.log file that results from running of the repro.

> ERROR XSDA7 while executing query that spills to BackingStoreHashTable
> ----------------------------------------------------------------------
>
>                 Key: DERBY-1939
>                 URL: http://issues.apache.org/jira/browse/DERBY-1939
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.1.3.0, 10.1.3.1, 10.1.3.2
>            Reporter: A B
>         Attachments: d1939.java, d1939_log.txt
>
>
> I have a database with a large query that's failing in Derby 10.1 with:
>   ERROR XSDA7: Restore of a serializable or SQLData object of class , attempted to read more data than was
>   originally stored
> The error only occurs if I use a PreparedStatement for the query and if I specify a parameter marker for one particular equality operand.  If I replace the parameter with an actual value, the query runs without error.
> I was eventually able to come up with a standalone repro that uses nonsense tables and a nonsense query but still demonstrates the problem.  That said, the error does *not* occur in Derby 10.2 or main, so it has apparently been fixed in those codelines.
> I did some investigating and was eventually able to track the fix down to svn commit # 389202 (DERBY-690).  Before that checkin the query fails against 10.2, but after that it runs without error.  It turns out that there's one uncommented change in svn 389202 that seems to have fixed the problem, namely:
> Index: java/engine/org/apache/derby/impl/store/access/heap/HeapRowLocation.java
> ===================================================================
> --- java/engine/org/apache/derby/impl/store/access/heap/HeapRowLocation.java	(revision 389043)
> +++ java/engine/org/apache/derby/impl/store/access/heap/HeapRowLocation.java	(working copy)
> @@ -104,7 +104,7 @@
>     }
>  
>      public DataValueDescriptor getNewNull() {
> -        return null;
> +        return new HeapRowLocation();
>     }
>  
> To confirm I undid this one line change in the 10.3 codeline and then the query started failing there.  Similarly, after I made this one-line change in the latest 10.1 codeline, the query started running successfully.  So apparently this is the fix to the problem...though I don't really know why...?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] Closed: (DERBY-1939) ERROR XSDA7 while executing query that spills to BackingStoreHashTable

Posted by "A B (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/DERBY-1939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

A B closed DERBY-1939.
----------------------


> ERROR XSDA7 while executing query that spills to BackingStoreHashTable
> ----------------------------------------------------------------------
>
>                 Key: DERBY-1939
>                 URL: https://issues.apache.org/jira/browse/DERBY-1939
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.1.3.1, 10.1.3.2
>            Reporter: A B
>         Assigned To: Mike Matrigali
>             Fix For: 10.1.3.2
>
>         Attachments: d1939.java, d1939_log.txt
>
>
> I have a database with a large query that's failing in Derby 10.1 with:
>   ERROR XSDA7: Restore of a serializable or SQLData object of class , attempted to read more data than was
>   originally stored
> The error only occurs if I use a PreparedStatement for the query and if I specify a parameter marker for one particular equality operand.  If I replace the parameter with an actual value, the query runs without error.
> I was eventually able to come up with a standalone repro that uses nonsense tables and a nonsense query but still demonstrates the problem.  That said, the error does *not* occur in Derby 10.2 or main, so it has apparently been fixed in those codelines.
> I did some investigating and was eventually able to track the fix down to svn commit # 389202 (DERBY-690).  Before that checkin the query fails against 10.2, but after that it runs without error.  It turns out that there's one uncommented change in svn 389202 that seems to have fixed the problem, namely:
> Index: java/engine/org/apache/derby/impl/store/access/heap/HeapRowLocation.java
> ===================================================================
> --- java/engine/org/apache/derby/impl/store/access/heap/HeapRowLocation.java	(revision 389043)
> +++ java/engine/org/apache/derby/impl/store/access/heap/HeapRowLocation.java	(working copy)
> @@ -104,7 +104,7 @@
>     }
>  
>      public DataValueDescriptor getNewNull() {
> -        return null;
> +        return new HeapRowLocation();
>     }
>  
> To confirm I undid this one line change in the 10.3 codeline and then the query started failing there.  Similarly, after I made this one-line change in the latest 10.1 codeline, the query started running successfully.  So apparently this is the fix to the problem...though I don't really know why...?

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


[jira] Assigned: (DERBY-1939) ERROR XSDA7 while executing query that spills to BackingStoreHashTable

Posted by "Mike Matrigali (JIRA)" <de...@db.apache.org>.
     [ http://issues.apache.org/jira/browse/DERBY-1939?page=all ]

Mike Matrigali reassigned DERBY-1939:
-------------------------------------

    Assignee: Mike Matrigali

> ERROR XSDA7 while executing query that spills to BackingStoreHashTable
> ----------------------------------------------------------------------
>
>                 Key: DERBY-1939
>                 URL: http://issues.apache.org/jira/browse/DERBY-1939
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.1.3.0, 10.1.3.1, 10.1.3.2
>            Reporter: A B
>         Assigned To: Mike Matrigali
>         Attachments: d1939.java, d1939_log.txt
>
>
> I have a database with a large query that's failing in Derby 10.1 with:
>   ERROR XSDA7: Restore of a serializable or SQLData object of class , attempted to read more data than was
>   originally stored
> The error only occurs if I use a PreparedStatement for the query and if I specify a parameter marker for one particular equality operand.  If I replace the parameter with an actual value, the query runs without error.
> I was eventually able to come up with a standalone repro that uses nonsense tables and a nonsense query but still demonstrates the problem.  That said, the error does *not* occur in Derby 10.2 or main, so it has apparently been fixed in those codelines.
> I did some investigating and was eventually able to track the fix down to svn commit # 389202 (DERBY-690).  Before that checkin the query fails against 10.2, but after that it runs without error.  It turns out that there's one uncommented change in svn 389202 that seems to have fixed the problem, namely:
> Index: java/engine/org/apache/derby/impl/store/access/heap/HeapRowLocation.java
> ===================================================================
> --- java/engine/org/apache/derby/impl/store/access/heap/HeapRowLocation.java	(revision 389043)
> +++ java/engine/org/apache/derby/impl/store/access/heap/HeapRowLocation.java	(working copy)
> @@ -104,7 +104,7 @@
>     }
>  
>      public DataValueDescriptor getNewNull() {
> -        return null;
> +        return new HeapRowLocation();
>     }
>  
> To confirm I undid this one line change in the 10.3 codeline and then the query started failing there.  Similarly, after I made this one-line change in the latest 10.1 codeline, the query started running successfully.  So apparently this is the fix to the problem...though I don't really know why...?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira