[
https://issues.apache.org/jira/browse/DERBY-6504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Myrna van Lunteren updated DERBY-6504:
--------------------------------------
Attachment: derby.logtry4
derby.logtry2
derby.logtry1
Attaching 3 sample log files.
derby.logtry1 is from a run without including the exception as the second
parameter in the StandardException. it shows the new XSDG4/UNABLE_TO_ARRAYCOPY
message, but of course no ArrayIndexOutOfBoundsException.
derby.logtry2 is from a run with including the exception as the second
parameter. The XSDG4 message does not show up - I'm still confused by this.
derby.logtry4 is the result of wrapping the new message in another message. In
this case we at least see both the ArrayIndexOutOfBounds and the XSDG4 message,
although a lot of stack output is taken up by the theoretically unnecessary
'DATA_UNEXPECTED_EXCEPTION'.
> change AllocPage.ReadContainerInfo to catch ArrayIndexOutOfBoundsException
> and turn it into Derby error.
> --------------------------------------------------------------------------------------------------------
>
> Key: DERBY-6504
> URL: https://issues.apache.org/jira/browse/DERBY-6504
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.6.1.0, 10.8.2.2
> Reporter: Mike Matrigali
> Assignee: Myrna van Lunteren
> Attachments: DERBY-6504.diff, derby.logtry1, derby.logtry2,
> derby.logtry4
>
>
> Users have reported databases that will not boot with stack traces showing:
> Caused by: java.lang.ArrayIndexOutOfBoundsException
> at java.lang.System.arraycopy(Native Method)
> at org.apache.derby.impl.store.raw.data.AllocPage.ReadContainerInfo(Unknown
> Source)
> at org.apache.derby.impl.store.raw.data.FileContainer.readHeader(Unknown
> Source)
> I suggest the code be changed to catch the out of bounds and turn it
> into a StandardException and include as much runtime information as
> possible so that the underlying problem can be diagnosed. Information
> should include sizes of both arrays, the amount of data being copied ("N"),
> and possibly a hex dump of the source array.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
