[
https://issues.apache.org/jira/browse/HDFS-7938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14364704#comment-14364704
]
Kiran Kumar M R commented on HDFS-7938:
---------------------------------------
I am continuing discussion on [~cmccabe] comment
https://issues.apache.org/jira/browse/HADOOP-11638?focusedCommentId=14364215&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14364215
bq. I looked at this and found that {{pthread_threadid_np}} on Mac has the type
signature: {{int pthread_threadid_np(pthread_t thread, __uint64_t *thread_id)}}
This doesn't match with using an {{unsigned long}}. I'm not sure under what
conditions an unsigned long is different than a {{uint64_t}} on Mac (on Linux,
that would be the case with 32-bit compilation). So this patch may have a
buffer overflow in that case.
I agree there may be a buffer overflow in case of 32-bit compilation on Mac. I
went ahead with patch since 64-bit build was mostly used. I will submit a patch
soon to use {{uint64_t}} and cast it to {{unsigned long}}
> OpensslSecureRandom.c pthread_threadid_np usage signature is wrong on 32-bit
> Mac
> --------------------------------------------------------------------------------
>
> Key: HDFS-7938
> URL: https://issues.apache.org/jira/browse/HDFS-7938
> Project: Hadoop HDFS
> Issue Type: Bug
> Affects Versions: 2.7.0
> Reporter: Colin Patrick McCabe
> Assignee: Kiran Kumar M R
> Priority: Critical
>
> In OpensslSecureRandom.c, pthread_threadid_np is being used with an unsigned
> long, but the type signature requires a uint64_t.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
