crunch-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Wills (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (CRUNCH-520) Fix minor potential bugs, minor cleanup from second Coverity Scan
Date Wed, 20 May 2015 16:39:00 GMT

     [ https://issues.apache.org/jira/browse/CRUNCH-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Josh Wills resolved CRUNCH-520.
-------------------------------
       Resolution: Fixed
    Fix Version/s: 0.13.0

Pushed to master. Thanks Sean!

> Fix minor potential bugs, minor cleanup from second Coverity Scan
> -----------------------------------------------------------------
>
>                 Key: CRUNCH-520
>                 URL: https://issues.apache.org/jira/browse/CRUNCH-520
>             Project: Crunch
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 0.11.0
>            Reporter: Sean Owen
>            Assignee: Josh Wills
>            Priority: Minor
>             Fix For: 0.13.0
>
>         Attachments: CRUNCH-520.patch
>
>
> As mentioned on the mailing list, I ran a Coverity scan (https://scan.coverity.com/projects/1983?tab=overview)
again and it turned up a reasonable number of little things to fix or touch up in the code.
See previous work in https://issues.apache.org/jira/browse/CRUNCH-380
> Cross-cutting minor touch-ups are:
> - Replace use of old junit.framework.* with org.unit.* for consistency
> - Remove some unused imports
> - String.getBytes() -> String.getBytes(Charset) to avoid platform dependence
> - Remove a few dead stores
> - Replace one Map.keySet() + many get()s with Map.entrySet() iteration
> - Remove a few @Nullable on method args that can't be (immediately dereferenced)
> - Closing some objects in a finally block that are Closable
> - Math.abs is technically a bad idea for something that can == Integer.MIN_VALUE
> There are a few changes that might be minor bug fixes:
> Aggregators:1059
> "maxInputLength > 0 && next.length() > maxInputLength" also needs a check
for next != null, but doesn't the second clause also need parentheses?
> TupleWritable:337
> The call to skip() doesn't check that the expected number of bytes were skipped.
> OrcWritable
> Missing hashCode for equals
> WritableGroupedTableType:97
> options is checked for null but is always dereferenced at the end
> CrunchOutputs:201
> baseContext can't be null at this point because of line 192
> SparkRuntime:342
> Not a bug but redundant I think since this occurs inside a block also guarded by "if
(t instance MapReduceTarget) {"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message