hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Nauroth (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-10027) *Compressor_deflateBytesDirect passes instance instead of jclass to GetStaticObjectField
Date Thu, 26 Feb 2015 22:21:04 GMT

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

Chris Nauroth commented on HADOOP-10027:
----------------------------------------

My best friend, the git blame log, tells me that this traces back to commit 9e22afd8704f62e312e749ebdb882455569de560,
which was HADOOP-3604 from 2008.  We should be able to use the information in that issue to
trace back to specific JVM versions that exhibited this bug.  Assuming those are all very
old JVM versions, then I am +1 for the approach of removing this locking completely.  Thanks
for taking this on [~huizheng].

> *Compressor_deflateBytesDirect passes instance instead of jclass to GetStaticObjectField
> ----------------------------------------------------------------------------------------
>
>                 Key: HADOOP-10027
>                 URL: https://issues.apache.org/jira/browse/HADOOP-10027
>             Project: Hadoop Common
>          Issue Type: Bug
>          Components: native
>            Reporter: Eric Abbott
>            Assignee: Hui Zheng
>            Priority: Minor
>         Attachments: HADOOP-10027.1.patch
>
>
> http://svn.apache.org/viewvc/hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/native/src/org/apache/hadoop/io/compress/zlib/ZlibCompressor.c?view=markup
> This pattern appears in all the native compressors.
>     // Get members of ZlibCompressor
>     jobject clazz = (*env)->GetStaticObjectField(env, this,
>                                                  ZlibCompressor_clazz);
> The 2nd argument to GetStaticObjectField is supposed to be a jclass, not a jobject. Adding
the JVM param -Xcheck:jni will cause "FATAL ERROR in native method: JNI received a class argument
that is not a class" and a core dump such as the following.
> (gdb) 
> #0 0x00007f02e4aef8a5 in raise () from /lib64/libc.so.6
> #1 0x00007f02e4af1085 in abort () from /lib64/libc.so.6
> #2 0x00007f02e45bd727 in os::abort(bool) () from /opt/jdk1.6.0_31/jre/lib/amd64/server/libjvm.so
> #3 0x00007f02e43cec63 in jniCheck::validate_class(JavaThread*, _jclass*, bool) () from
/opt/jdk1.6.0_31/jre/lib/amd64/server/libjvm.so
> #4 0x00007f02e43ea669 in checked_jni_GetStaticObjectField () from /opt/jdk1.6.0_31/jre/lib/amd64/server/libjvm.so
> #5 0x00007f02d38eaf79 in Java_org_apache_hadoop_io_compress_zlib_ZlibCompressor_deflateBytesDirect
() from /usr/lib/hadoop/lib/native/libhadoop.so.1.0.0
> In addition, that clazz object is only used for synchronization. In the case of the native
method _deflateBytesDirect, the result is a class wide lock used to access the instance field
uncompressed_direct_buf. Perhaps using the instance as the sync point is more appropriate?



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

Mime
View raw message