[
https://issues.apache.org/jira/browse/HADOOP-11526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14298281#comment-14298281
]
Chris Nauroth commented on HADOOP-11526:
----------------------------------------
Thank you for the bug report, Ian. Fortunately, this function is generally
only called during one-time initialization in a Hadoop process, so that lessens
the severity of the leak. We can still fix it though.
Our native codebase is in C, so we'll have to stick with doing our own resource
management instead of the smart pointers.
> Memory leak in Bzip2Decompressor
> --------------------------------
>
> Key: HADOOP-11526
> URL: https://issues.apache.org/jira/browse/HADOOP-11526
> Project: Hadoop Common
> Issue Type: Bug
> Components: io
> Reporter: Ian Rogers
>
> The use of JNI's GetStringUTFChars should be paired with
> ReleaseStringUTFChars or else the utf-8 char* created by Java's JNI
> implementation is leaked. It isn't in Bzip2Decompressor.c:
> https://apache.googlesource.com/hadoop-common/+/refs/heads/trunk/hadoop-common-project/hadoop-common/src/main/native/src/org/apache/hadoop/io/compress/bzip2/Bzip2Decompressor.c#45
> A less error-prone way of handling JNI resources like local references and
> UTF strings is to use a smart pointer like the Apache licensed code in
> Android's ScopedLocalRef and ScopedUtfChars:
> https://android.googlesource.com/platform/libnativehelper/+/jb-mr1.1-dev-plus-aosp/include/nativehelper/ScopedLocalRef.h
> https://android.googlesource.com/platform/libnativehelper/+/jb-mr1.1-dev-plus-aosp/include/nativehelper/ScopedUtfChars.h
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)