[ 
https://issues.apache.org/jira/browse/HADOOP-12567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15009862#comment-15009862
 ] 

Chris Nauroth commented on HADOOP-12567:
----------------------------------------

The test failures are unrelated, and I cannot reproduce locally.  
{{TestDecayRpcScheduler}}, like many of the RPC tests, is known to be racy.  
{{TestSymlinkLocalFSFileContext}} failed for a very unusual reason that appears 
to be specific to the environment on that Jenkins host.  (See below.)  I'll 
commit this later today.

{code}
Tests run: 63, Failures: 0, Errors: 1, Skipped: 3, Time elapsed: 2.869 sec <<< 
FAILURE! - in org.apache.hadoop.fs.TestSymlinkLocalFSFileContext
testStatLinkToDir(org.apache.hadoop.fs.TestSymlinkLocalFSFileContext)  Time 
elapsed: 0.033 sec  <<< ERROR!
java.io.IOException: Unexpected stat output: stat: error while loading shared 
libraries: libdl.so.2: failed to map segment from shared object: Permission 
denied
        at org.apache.hadoop.fs.Stat.parseExecResult(Stat.java:169)
{code}


> NPE in SaslRpcServer
> --------------------
>
>                 Key: HADOOP-12567
>                 URL: https://issues.apache.org/jira/browse/HADOOP-12567
>             Project: Hadoop Common
>          Issue Type: Task
>    Affects Versions: 2.7.0, 2.7.1
>            Reporter: Sergey Shelukhin
>            Assignee: Sergey Shelukhin
>         Attachments: HADOOP-12567.01.patch, HADOOP-12567.patch
>
>
> {noformat}
> if (LOG.isDebugEnabled()) {
>             String username =
>               getIdentifier(authzid, secretManager).getUser().getUserName();
>             LOG.debug("SASL server DIGEST-MD5 callback: setting "
>                 + "canonicalized client ID: " + username);
>           }
> {noformat}
> Looking at identifier implementations, e.g. AbstractDelegationTokenIdentifier 
> (and others), I can see that getUser method can return null. If debug logging 
> is enabled, this NPEs.
> If getUser is not expected to return NULL, it should either be checked and 
> erred upon better here, or the error should be allowed to happen where it 
> would otherwise happen, not in some debug log path.



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

Reply via email to