[
https://issues.apache.org/jira/browse/HADOOP-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14524571#comment-14524571
]
Hadoop QA commented on HADOOP-7651:
-----------------------------------
\\
\\
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:red}-1{color} | patch | 0m 0s | The patch command could not apply
the patch during dryrun. |
\\
\\
|| Subsystem || Report/Notes ||
| Patch URL |
http://issues.apache.org/jira/secure/attachment/12499462/7651-22.patch |
| Optional Tests | javadoc javac unit findbugs checkstyle |
| git revision | trunk / f1a152c |
| Console output |
https://builds.apache.org/job/PreCommit-HADOOP-Build/6263/console |
This message was automatically generated.
> Hadoop Record compiler generates Java files with erroneous byte-array lengths
> for fields trailing a 'ustring' field
> -------------------------------------------------------------------------------------------------------------------
>
> Key: HADOOP-7651
> URL: https://issues.apache.org/jira/browse/HADOOP-7651
> Project: Hadoop Common
> Issue Type: Bug
> Components: record
> Affects Versions: 0.20.2
> Reporter: Hung-chih Yang
> Assignee: Milind Bhandarkar
> Labels: hadoop
> Attachments: 7651-22.patch, 7651-trunk.patch
>
> Original Estimate: 1m
> Remaining Estimate: 1m
>
> Hadoop Record compiler produces Java files from a DDL file. If a DDL file has
> a class that contains a 'ustring' field, then the generated 'compareRaw()'
> function for this record is erroneous in computing the length of remaining
> bytes after the logic of computing the buffer segment for a 'ustring' field.
> Below is a line in a generated 'compareRaw()' function for a record class
> with a 'ustring' field :
> s1+=i1; s2+=i2; l1-=i1; l1-=i2;
> This line shoud be corrected by changing the last 'l1' to 'l2':
> s1+=i1; s2+=i2; l1-=i1; l2-=i2;
> To fix this bug, one should correct the 'genCompareBytes()' function in the
> 'JString.java' file of the package 'org.apache.hadoop.record.compiler' by
> changing the line below to the ensuing line. There is only one digit
> difference:
> cb.append("s1+=i1; s2+=i2; l1-=i1; l1-=i2;\n");
> cb.append("s1+=i1; s2+=i2; l1-=i1; l2-=i2;\n");
> This bug is serious as it will always crash unserializing a record with a
> simple definition like the one below
> class PairStringDouble {
> ustring first;
> double second;
> }
> Unserializing a record of this class will throw an exception as the 'second'
> field does not have 8 bytes for a double value due to the erroneous length
> computation for the remaining buffer.
> Both Hadoop 0.20 and 0.21 have this bug.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
