Hadoop Common
  1. Hadoop Common
  2. HADOOP-10542

Potential null pointer dereference in Jets3tFileSystemStore#retrieveBlock()

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.6.0
    • Fix Version/s: 2.7.0
    • Component/s: fs/s3
    • Labels:
      None
    • Target Version/s:

      Description

            in = get(blockToKey(block), byteRangeStart);
            out = new BufferedOutputStream(new FileOutputStream(fileBlock));
            byte[] buf = new byte[bufferSize];
            int numRead;
            while ((numRead = in.read(buf)) >= 0) {
      

      get() may return null.
      The while loop dereferences in without null check.

        Issue Links

          Activity

          Hide
          Steve Loughran added a comment -

          I think we need to look at why the error "NoSuchKey" is being mapped to null, rather than raise an exception -and for the selective reporting in handleServiceException(). Do that -and provide a useful error, and the deref here goes away.

          HADOOP-10533 seems related.

          Show
          Steve Loughran added a comment - I think we need to look at why the error "NoSuchKey" is being mapped to null , rather than raise an exception -and for the selective reporting in handleServiceException() . Do that -and provide a useful error, and the deref here goes away. HADOOP-10533 seems related.
          Hide
          Steve Loughran added a comment -

          this still exists in 2.6. Ted: do you have a patch for this?

          Show
          Steve Loughran added a comment - this still exists in 2.6. Ted: do you have a patch for this?
          Hide
          Ted Yu added a comment -

          If in is null, do we return an empty fileBlock or raise exception ?
          I lean toward the latter. e.g. raise IOE with message saying object with key blockToKey(block) wasn't found.

          Show
          Ted Yu added a comment - If in is null, do we return an empty fileBlock or raise exception ? I lean toward the latter. e.g. raise IOE with message saying object with key blockToKey(block) wasn't found.
          Hide
          Steve Loughran added a comment -

          IOE: it's the only thing that ensures callers won't themselves NPE

          Show
          Steve Loughran added a comment - IOE: it's the only thing that ensures callers won't themselves NPE
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12692922/hadoop-10542-001.patch
          against trunk revision 43302f6.

          +1 @author. The patch does not contain any @author tags.

          -1 tests included. The patch doesn't appear to include any new or modified tests.
          Please justify why no new tests are needed for this patch.
          Also please list what manual steps were performed to verify this patch.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 javadoc. There were no new javadoc warning messages.

          +1 eclipse:eclipse. The patch built with eclipse:eclipse.

          +1 findbugs. The patch does not introduce any new Findbugs (version 2.0.3) warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          +1 core tests. The patch passed unit tests in hadoop-tools/hadoop-aws.

          Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/5422//testReport/
          Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/5422//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12692922/hadoop-10542-001.patch against trunk revision 43302f6. +1 @author . The patch does not contain any @author tags. -1 tests included . The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. +1 javac . The applied patch does not increase the total number of javac compiler warnings. +1 javadoc . There were no new javadoc warning messages. +1 eclipse:eclipse . The patch built with eclipse:eclipse. +1 findbugs . The patch does not introduce any new Findbugs (version 2.0.3) warnings. +1 release audit . The applied patch does not increase the total number of release audit warnings. +1 core tests . The patch passed unit tests in hadoop-tools/hadoop-aws. Test results: https://builds.apache.org/job/PreCommit-HADOOP-Build/5422//testReport/ Console output: https://builds.apache.org/job/PreCommit-HADOOP-Build/5422//console This message is automatically generated.
          Hide
          Steve Loughran added a comment -

          +1, committing

          Show
          Steve Loughran added a comment - +1, committing
          Hide
          Hudson added a comment -

          FAILURE: Integrated in Hadoop-trunk-Commit #6882 (See https://builds.apache.org/job/Hadoop-trunk-Commit/6882/)
          HADOOP-10542 Potential null pointer dereference in Jets3tFileSystemStore retrieveBlock(). (Ted Yu via stevel) (stevel: rev c6c0f4eb25e511944915bc869e741197f7a277e0)

          • hadoop-tools/hadoop-aws/src/main/java/org/apache/hadoop/fs/s3/Jets3tFileSystemStore.java
          • hadoop-common-project/hadoop-common/CHANGES.txt
          Show
          Hudson added a comment - FAILURE: Integrated in Hadoop-trunk-Commit #6882 (See https://builds.apache.org/job/Hadoop-trunk-Commit/6882/ ) HADOOP-10542 Potential null pointer dereference in Jets3tFileSystemStore retrieveBlock(). (Ted Yu via stevel) (stevel: rev c6c0f4eb25e511944915bc869e741197f7a277e0) hadoop-tools/hadoop-aws/src/main/java/org/apache/hadoop/fs/s3/Jets3tFileSystemStore.java hadoop-common-project/hadoop-common/CHANGES.txt
          Hide
          Hudson added a comment -

          FAILURE: Integrated in Hadoop-Yarn-trunk-Java8 #77 (See https://builds.apache.org/job/Hadoop-Yarn-trunk-Java8/77/)
          HADOOP-10542 Potential null pointer dereference in Jets3tFileSystemStore retrieveBlock(). (Ted Yu via stevel) (stevel: rev c6c0f4eb25e511944915bc869e741197f7a277e0)

          • hadoop-common-project/hadoop-common/CHANGES.txt
          • hadoop-tools/hadoop-aws/src/main/java/org/apache/hadoop/fs/s3/Jets3tFileSystemStore.java
          Show
          Hudson added a comment - FAILURE: Integrated in Hadoop-Yarn-trunk-Java8 #77 (See https://builds.apache.org/job/Hadoop-Yarn-trunk-Java8/77/ ) HADOOP-10542 Potential null pointer dereference in Jets3tFileSystemStore retrieveBlock(). (Ted Yu via stevel) (stevel: rev c6c0f4eb25e511944915bc869e741197f7a277e0) hadoop-common-project/hadoop-common/CHANGES.txt hadoop-tools/hadoop-aws/src/main/java/org/apache/hadoop/fs/s3/Jets3tFileSystemStore.java
          Hide
          Hudson added a comment -

          FAILURE: Integrated in Hadoop-Yarn-trunk #811 (See https://builds.apache.org/job/Hadoop-Yarn-trunk/811/)
          HADOOP-10542 Potential null pointer dereference in Jets3tFileSystemStore retrieveBlock(). (Ted Yu via stevel) (stevel: rev c6c0f4eb25e511944915bc869e741197f7a277e0)

          • hadoop-tools/hadoop-aws/src/main/java/org/apache/hadoop/fs/s3/Jets3tFileSystemStore.java
          • hadoop-common-project/hadoop-common/CHANGES.txt
          Show
          Hudson added a comment - FAILURE: Integrated in Hadoop-Yarn-trunk #811 (See https://builds.apache.org/job/Hadoop-Yarn-trunk/811/ ) HADOOP-10542 Potential null pointer dereference in Jets3tFileSystemStore retrieveBlock(). (Ted Yu via stevel) (stevel: rev c6c0f4eb25e511944915bc869e741197f7a277e0) hadoop-tools/hadoop-aws/src/main/java/org/apache/hadoop/fs/s3/Jets3tFileSystemStore.java hadoop-common-project/hadoop-common/CHANGES.txt
          Hide
          Hudson added a comment -

          FAILURE: Integrated in Hadoop-Hdfs-trunk #2009 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk/2009/)
          HADOOP-10542 Potential null pointer dereference in Jets3tFileSystemStore retrieveBlock(). (Ted Yu via stevel) (stevel: rev c6c0f4eb25e511944915bc869e741197f7a277e0)

          • hadoop-tools/hadoop-aws/src/main/java/org/apache/hadoop/fs/s3/Jets3tFileSystemStore.java
          • hadoop-common-project/hadoop-common/CHANGES.txt
          Show
          Hudson added a comment - FAILURE: Integrated in Hadoop-Hdfs-trunk #2009 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk/2009/ ) HADOOP-10542 Potential null pointer dereference in Jets3tFileSystemStore retrieveBlock(). (Ted Yu via stevel) (stevel: rev c6c0f4eb25e511944915bc869e741197f7a277e0) hadoop-tools/hadoop-aws/src/main/java/org/apache/hadoop/fs/s3/Jets3tFileSystemStore.java hadoop-common-project/hadoop-common/CHANGES.txt
          Hide
          Hudson added a comment -

          FAILURE: Integrated in Hadoop-Hdfs-trunk-Java8 #74 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk-Java8/74/)
          HADOOP-10542 Potential null pointer dereference in Jets3tFileSystemStore retrieveBlock(). (Ted Yu via stevel) (stevel: rev c6c0f4eb25e511944915bc869e741197f7a277e0)

          • hadoop-tools/hadoop-aws/src/main/java/org/apache/hadoop/fs/s3/Jets3tFileSystemStore.java
          • hadoop-common-project/hadoop-common/CHANGES.txt
          Show
          Hudson added a comment - FAILURE: Integrated in Hadoop-Hdfs-trunk-Java8 #74 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk-Java8/74/ ) HADOOP-10542 Potential null pointer dereference in Jets3tFileSystemStore retrieveBlock(). (Ted Yu via stevel) (stevel: rev c6c0f4eb25e511944915bc869e741197f7a277e0) hadoop-tools/hadoop-aws/src/main/java/org/apache/hadoop/fs/s3/Jets3tFileSystemStore.java hadoop-common-project/hadoop-common/CHANGES.txt
          Hide
          Hudson added a comment -

          FAILURE: Integrated in Hadoop-Mapreduce-trunk-Java8 #78 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk-Java8/78/)
          HADOOP-10542 Potential null pointer dereference in Jets3tFileSystemStore retrieveBlock(). (Ted Yu via stevel) (stevel: rev c6c0f4eb25e511944915bc869e741197f7a277e0)

          • hadoop-tools/hadoop-aws/src/main/java/org/apache/hadoop/fs/s3/Jets3tFileSystemStore.java
          • hadoop-common-project/hadoop-common/CHANGES.txt
          Show
          Hudson added a comment - FAILURE: Integrated in Hadoop-Mapreduce-trunk-Java8 #78 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk-Java8/78/ ) HADOOP-10542 Potential null pointer dereference in Jets3tFileSystemStore retrieveBlock(). (Ted Yu via stevel) (stevel: rev c6c0f4eb25e511944915bc869e741197f7a277e0) hadoop-tools/hadoop-aws/src/main/java/org/apache/hadoop/fs/s3/Jets3tFileSystemStore.java hadoop-common-project/hadoop-common/CHANGES.txt
          Hide
          Hudson added a comment -

          FAILURE: Integrated in Hadoop-Mapreduce-trunk #2028 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk/2028/)
          HADOOP-10542 Potential null pointer dereference in Jets3tFileSystemStore retrieveBlock(). (Ted Yu via stevel) (stevel: rev c6c0f4eb25e511944915bc869e741197f7a277e0)

          • hadoop-tools/hadoop-aws/src/main/java/org/apache/hadoop/fs/s3/Jets3tFileSystemStore.java
          • hadoop-common-project/hadoop-common/CHANGES.txt
          Show
          Hudson added a comment - FAILURE: Integrated in Hadoop-Mapreduce-trunk #2028 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk/2028/ ) HADOOP-10542 Potential null pointer dereference in Jets3tFileSystemStore retrieveBlock(). (Ted Yu via stevel) (stevel: rev c6c0f4eb25e511944915bc869e741197f7a277e0) hadoop-tools/hadoop-aws/src/main/java/org/apache/hadoop/fs/s3/Jets3tFileSystemStore.java hadoop-common-project/hadoop-common/CHANGES.txt
          Hide
          Matthew Paduano added a comment -

          This change seems to break some things. In particular, have a closer look at:

          S3FileSystem.getFileStatus() (which no longer raises FileNotFoundException but instead IOException)
          FileSystem.exists() (which no longer returns false but instead raises IOException)
          S3FileSystem.create() (which no longer succeeds but instead raises IOException)

          While the javadoc suggests that the API permits one to raise IOException, most of the code I have
          encountered while debugging a command like "hadoop distcp hdfs://localhost:9000/test s3://xxx:yyy@com.bar.foo/"
          seems to expect (1) retrieveINode() to return null and (2) FileNotFoundException to be raised when a file is not
          found (i.e. when get() fails!).

          2015-12-11 10:04:34,030 FATAL [IPC Server handler 6 on 44861] org.apache.hadoop.mapred.TaskAttemptListenerImpl: Task: attempt_1449826461866_0005_m_000006_0 - exited : java.io.IOException: /test doesn't exist
          at org.apache.hadoop.fs.s3.Jets3tFileSystemStore.get(Jets3tFileSystemStore.java:170)
          at org.apache.hadoop.fs.s3.Jets3tFileSystemStore.retrieveINode(Jets3tFileSystemStore.java:221)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
          at java.lang.reflect.Method.invoke(Method.java:606)
          at org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:187)
          at org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:102)
          at com.sun.proxy.$Proxy17.retrieveINode(Unknown Source)
          at org.apache.hadoop.fs.s3.S3FileSystem.getFileStatus(S3FileSystem.java:340)
          at org.apache.hadoop.tools.mapred.CopyMapper.map(CopyMapper.java:230)
          at org.apache.hadoop.tools.mapred.CopyMapper.map(CopyMapper.java:50)
          at org.apache.hadoop.mapreduce.Mapper.run(Mapper.java:146)
          at org.apache.hadoop.mapred.MapTask.runNewMapper(MapTask.java:787)
          at org.apache.hadoop.mapred.MapTask.run(MapTask.java:341)
          at org.apache.hadoop.mapred.YarnChild$2.run(YarnChild.java:164)
          at java.security.AccessController.doPrivileged(Native Method)
          at javax.security.auth.Subject.doAs(Subject.java:415)
          at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1657)
          at org.apache.hadoop.mapred.YarnChild.main(YarnChild.java:158)

          changing the "raise IOE..." to "return null" fixes all of the above code sites and
          allows distcp to succeed.

          Show
          Matthew Paduano added a comment - This change seems to break some things. In particular, have a closer look at: S3FileSystem.getFileStatus() (which no longer raises FileNotFoundException but instead IOException) FileSystem.exists() (which no longer returns false but instead raises IOException) S3FileSystem.create() (which no longer succeeds but instead raises IOException) While the javadoc suggests that the API permits one to raise IOException, most of the code I have encountered while debugging a command like "hadoop distcp hdfs://localhost:9000/test s3://xxx:yyy@com.bar.foo/" seems to expect (1) retrieveINode() to return null and (2) FileNotFoundException to be raised when a file is not found (i.e. when get() fails!). 2015-12-11 10:04:34,030 FATAL [IPC Server handler 6 on 44861] org.apache.hadoop.mapred.TaskAttemptListenerImpl: Task: attempt_1449826461866_0005_m_000006_0 - exited : java.io.IOException: /test doesn't exist at org.apache.hadoop.fs.s3.Jets3tFileSystemStore.get(Jets3tFileSystemStore.java:170) at org.apache.hadoop.fs.s3.Jets3tFileSystemStore.retrieveINode(Jets3tFileSystemStore.java:221) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:187) at org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:102) at com.sun.proxy.$Proxy17.retrieveINode(Unknown Source) at org.apache.hadoop.fs.s3.S3FileSystem.getFileStatus(S3FileSystem.java:340) at org.apache.hadoop.tools.mapred.CopyMapper.map(CopyMapper.java:230) at org.apache.hadoop.tools.mapred.CopyMapper.map(CopyMapper.java:50) at org.apache.hadoop.mapreduce.Mapper.run(Mapper.java:146) at org.apache.hadoop.mapred.MapTask.runNewMapper(MapTask.java:787) at org.apache.hadoop.mapred.MapTask.run(MapTask.java:341) at org.apache.hadoop.mapred.YarnChild$2.run(YarnChild.java:164) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:415) at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1657) at org.apache.hadoop.mapred.YarnChild.main(YarnChild.java:158) changing the "raise IOE..." to "return null" fixes all of the above code sites and allows distcp to succeed.
          Hide
          Steve Loughran added a comment -

          Matt -can you create a new JIRA on that; tag it as caused-by this one?

          s3n is a perennial troublespot, though I'm surprised that what you are seeing crept through

          Show
          Steve Loughran added a comment - Matt -can you create a new JIRA on that; tag it as caused-by this one? s3n is a perennial troublespot, though I'm surprised that what you are seeing crept through

            People

            • Assignee:
              Ted Yu
              Reporter:
              Ted Yu
            • Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development