db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Korneliussen (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1497) assert failure in MessageUtil, because exception thrown with too many parameters when handling OutOfMemoryError
Date Tue, 11 Jul 2006 15:01:30 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1497?page=comments#action_12420328 ] 

Andreas Korneliussen commented on DERBY-1497:
---------------------------------------------

Sure that would be an improvement. It would only work on java 6, since other VMs do not give
a stack trace on OutOfMemoryError.

Before the patch, the stack trace from OutOfMemoryError was already lost, since the code used
this constructor of DisconnectException:
 public DisconnectException(Agent agent, ClientMessageId msgid, Object arg1) {
        this(agent, msgid, new Object[] { arg1 });
    }

which at some point would call:

public DisconnectException(Agent agent, ClientMessageId msgid,
        Object[] args, SqlCode sqlcode) {
        this(agent, msgid, args, sqlcode, (Throwable)null);
    }
(The OutOfMemoryException is part of args, not throwable, and its stacktrace lost)

> assert failure in MessageUtil, because exception thrown with too many parameters when
handling OutOfMemoryError
> ---------------------------------------------------------------------------------------------------------------
>
>          Key: DERBY-1497
>          URL: http://issues.apache.org/jira/browse/DERBY-1497
>      Project: Derby
>         Type: Sub-task

>   Components: Network Client
>     Versions: 10.2.0.0
>     Reporter: Andreas Korneliussen
>     Assignee: Andreas Korneliussen
>     Priority: Trivial
>      Fix For: 10.2.0.0
>  Attachments: DERBY-1497.diff
>
> If the VM throws a OutOfMemoryException, which is caught in:
> NetStatementReply.copyEXTDTA:
>     protected void copyEXTDTA(NetCursor netCursor) throws DisconnectException {
>         try {
>             parseLengthAndMatchCodePoint(CodePoint.EXTDTA);
>             byte[] data = null;
>             if (longValueForDecryption_ == null) {
>                 data = (getData(null)).toByteArray();
>             } else {
>                 data = longValueForDecryption_;
>                 dssLength_ = 0;
>                 longValueForDecryption_ = null;
>             }
>             netCursor.extdtaData_.add(data);
>         } catch (java.lang.OutOfMemoryError e) {     <--- outofmemory
>             agent_.accumulateChainBreakingReadExceptionAndThrow(new DisconnectException(agent_,
>                 new ClientMessageId(SQLState.NET_LOB_DATA_TOO_LARGE_FOR_JVM),
>                 e));  <----- message does not take parameters, causing assert failure
>         }
>     } 
> Instead of getting the message: java.sql.SQLException: Attempt to fully materialize lob
data that is too large for the JVM.  The connection has been terminated.
> I am getting an assert: 
> Exception in thread "main" org.apache.derby.shared.common.sanity.AssertFailure: ASSERT
FAILED Number of parameters expected for message id 58009.C.6 (0) does not match number of
arguments received (1)
>         at org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:119)


-- 
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


Mime
View raw message