[
https://issues.apache.org/jira/browse/HADOOP-6834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12888939#action_12888939
]
Hadoop QA commented on HADOOP-6834:
-----------------------------------
-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12449597/hadoop-6834-20100715.patch
against trunk revision 964134.
+1 @author. The patch does not contain any @author tags.
+1 tests included. The patch appears to include 2 new or modified tests.
-1 javadoc. The javadoc tool appears to have generated 1 warning messages.
+1 javac. The applied patch does not increase the total number of javac
compiler warnings.
+1 findbugs. The patch does not introduce any new Findbugs warnings.
+1 release audit. The applied patch does not increase the total number of
release audit warnings.
+1 core tests. The patch passed core unit tests.
+1 contrib tests. The patch passed contrib unit tests.
Test results:
http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/617/testReport/
Findbugs warnings:
http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/617/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Checkstyle results:
http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/617/artifact/trunk/build/test/checkstyle-errors.html
Console output:
http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-h4.grid.sp2.yahoo.net/617/console
This message is automatically generated.
> TFile.append compares initial key against null lastKey
> --------------------------------------------------------
>
> Key: HADOOP-6834
> URL: https://issues.apache.org/jira/browse/HADOOP-6834
> Project: Hadoop Common
> Issue Type: Bug
> Components: io
> Affects Versions: 0.20.1, 0.20.2
> Reporter: Ahad Rana
> Assignee: Hong Tang
> Attachments: hadoop-6834-20100715.patch
>
>
> The following code in TFile.KeyReigster.close:
> byte[] lastKey = lastKeyBufferOS.getBuffer();
> int lastLen = lastKeyBufferOS.size();
> if (tfileMeta.getComparator().compare(key, 0, len, lastKey, 0,
> lastLen) < 0) {
> throw new IOException("Keys are not added in sorted order");
> }
> compares the initial key (passed in via TFile.Writer.append) against a
> technically NULL lastKey. lastKey is not initialized until after the first
> call to TFile.Writer.append. The underlying RawComparator interface used for
> comparisons does not stipulate the proper behavior when either length 1 or
> length 2 is zero. In the case of LongWritable, its WritableComparator
> implementation does an unsafe read on the passed in byte arrays b1 and b2.
> Since TFile pre-allocates the buffer used for storing lastKey, this passes a
> valid buffer with zero count to LongWritable's comparator, which ignores
> length and thus produces incorrect results.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
