[
https://issues.apache.org/jira/browse/DERBY-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543598
]
Knut Anders Hatlen commented on DERBY-3215:
-------------------------------------------
Here's the relevant part of CachedPage:
throw dataFactory.markCorrupt(
StandardException.newException(
SQLState.FILE_WRITE_PAGE_EXCEPTION, nested,
identity, new Integer(myContainer.getPageSize())));
What's interesting is that it passes in two arguments to the message builder
(identity and new Integer(...)). However, message.xml defines the message like
this:
<msg>
<name>XSDG1.D</name>
<text>Page {0} could not be written to disk, please check if
disk is full.</text>
<arg>page</arg>
</msg>
That is, there's only one argument, which is the page identity. So the
parameter which causes the NPE is not even used when the message is generated,
and it can probably be removed.
> Potential NullPointerException in CachedPage class
> --------------------------------------------------
>
> Key: DERBY-3215
> URL: https://issues.apache.org/jira/browse/DERBY-3215
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.3.1.4
> Environment: Windows XP
> Reporter: Jason Valentine
>
> There's a potential for a NullPointerException to be thrown in the in the
> org.apache.derby.impl.store.raw.data.CachedPage class. In the writePage()
> method, there's a test of the myContainer reference to ensure it's not null
> (line 771), however in the else block, myContainer is dereferenced (line
> 836), where a NullPointerException is guaranteed to be thrown.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
