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

Sailesh Mukil commented on HDFS-12494:
--------------------------------------

[~jzhuge] Thanks for submitting the patch.

One question I have:

Shouldn't we now clear the TLS if a failure happens in getGlobalJNIEnv(), since 
we now set the TLS before calling getGlobalJNIEnv(), but that TLS has no 
associated JNIEnv? So the next time that thread calls getJNIEnv, it would get a 
TLS without a JNIEnv which would fail elsewhere.

> libhdfs SIGSEGV in setTLSExceptionStrings
> -----------------------------------------
>
>                 Key: HDFS-12494
>                 URL: https://issues.apache.org/jira/browse/HDFS-12494
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: libhdfs
>    Affects Versions: 3.0.0-alpha4
>            Reporter: John Zhuge
>            Assignee: John Zhuge
>         Attachments: HDFS-12494.001.patch
>
>
> libhdfs application crashes when CLASSPATH is set but not set properly. It 
> uses wildcard in this case.
> {noformat}
> $ export CLASSPATH=$(hadoop classpath)
> $ pwd
> /Users/jzhuge/hadoop2/hadoop-hdfs-project/hadoop-hdfs/target/native
> $ ./test_libhdfs_ops
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x00000001052968f7, pid=14147, tid=775
> #
> # JRE version: Java(TM) SE Runtime Environment (7.0_79-b15) (build 
> 1.7.0_79-b15)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.79-b02 mixed mode bsd-amd64 
> compressed oops)
> # Problematic frame:
> # C  [libhdfs.0.0.0.dylib+0x38f7]  setTLSExceptionStrings+0x47
> #
> # Core dump written. Default location: /cores/core or core.14147
> #
> # An error report file with more information is saved as:
> # 
> /Users/jzhuge/hadoop2/hadoop-hdfs-project/hadoop-hdfs/target/native/hs_err_pid14147.log
> #
> #
> # If you would like to submit a bug report, please visit:
> #   http://bugreport.java.com/bugreport/crash.jsp
> # The crash happened outside the Java Virtual Machine in native code.
> # See problematic frame for where to report the bug.
> #
> Abort trap: 6 (core dumped)
> [jzhuge@jzhuge-MBP native]((be32925fff5...) *+)$ lldb -c /cores/core.14147
> (lldb) target create --core "/cores/core.14147"
> warning: (x86_64) /cores/core.14147 load command 549 LC_SEGMENT_64 has a 
> fileoff + filesize (0x14627f000) that extends beyond the end of the file 
> (0x14627e000), the segment will be truncated to match
> warning: (x86_64) /cores/core.14147 load command 550 LC_SEGMENT_64 has a 
> fileoff (0x14627f000) that extends beyond the end of the file (0x14627e000), 
> ignoring this section
> Core file '/cores/core.14147' (x86_64) was loaded.
> (lldb) bt
> * thread #1, stop reason = signal SIGSTOP
>   * frame #0: 0x00007fffcf89ad42 libsystem_kernel.dylib`__pthread_kill + 10
>     frame #1: 0x00007fffcf988457 libsystem_pthread.dylib`pthread_kill + 90
>     frame #2: 0x00007fffcf800420 libsystem_c.dylib`abort + 129
>     frame #3: 0x00000001056cd5fb libjvm.dylib`os::abort(bool) + 25
>     frame #4: 0x00000001057d98fc libjvm.dylib`VMError::report_and_die() + 2308
>     frame #5: 0x00000001056cefb5 libjvm.dylib`JVM_handle_bsd_signal + 1083
>     frame #6: 0x00007fffcf97bb3a libsystem_platform.dylib`_sigtramp + 26
>     frame #7: 0x00000001052968f8 
> libhdfs.0.0.0.dylib`setTLSExceptionStrings(rootCause=0x0000000000000000, 
> stackTrace=0x0000000000000000) at jni_helper.c:589 [opt]
>     frame #8: 0x00000001052954f0 
> libhdfs.0.0.0.dylib`printExceptionAndFreeV(env=0x00007ffaff0019e8, 
> exc=0x00007ffafec04140, noPrintFlags=<unavailable>, fmt="loadFileSystems", 
> ap=<unavailable>) at exception.c:183 [opt]
>     frame #9: 0x00000001052956bb 
> libhdfs.0.0.0.dylib`printExceptionAndFree(env=<unavailable>, 
> exc=<unavailable>, noPrintFlags=<unavailable>, fmt=<unavailable>) at 
> exception.c:213 [opt]
>     frame #10: 0x00000001052967f4 libhdfs.0.0.0.dylib`getJNIEnv [inlined] 
> getGlobalJNIEnv at jni_helper.c:463 [opt]
>     frame #11: 0x000000010529664f libhdfs.0.0.0.dylib`getJNIEnv at 
> jni_helper.c:528 [opt]
>     frame #12: 0x00000001052975eb 
> libhdfs.0.0.0.dylib`hdfsBuilderConnect(bld=0x00007ffafed00000) at hdfs.c:693 
> [opt]
>     frame #13: 0x000000010528be30 test_libhdfs_ops`main(argc=<unavailable>, 
> argv=<unavailable>) at test_libhdfs_ops.c:91 [opt]
>     frame #14: 0x00007fffcf76c235 libdyld.dylib`start + 1
> (lldb) f 10
> libhdfs.0.0.0.dylib was compiled with optimization - stepping may behave 
> oddly; variables may not be available.
> frame #10: 0x00000001052967f4 libhdfs.0.0.0.dylib`getJNIEnv [inlined] 
> getGlobalJNIEnv at jni_helper.c:463 [opt]
>    460                                 "org/apache/hadoop/fs/FileSystem",
>    461                                 "loadFileSystems", "()V");
>    462                if (jthr) {
> -> 463                    printExceptionAndFree(env, jthr, PRINT_EXC_ALL, 
> "loadFileSystems");
>    464                }
>    465            }
>    466            else {
> (lldb) f 7
> frame #7: 0x00000001052968f8 
> libhdfs.0.0.0.dylib`setTLSExceptionStrings(rootCause=0x0000000000000000, 
> stackTrace=0x0000000000000000) at jni_helper.c:589 [opt]
>    586                mutexUnlock(&jvmMutex);
>    587            }
>    588
> -> 589            free(state->lastExceptionRootCause);
>    590            free(state->lastExceptionStackTrace);
>    591            state->lastExceptionRootCause = (char*)rootCause;
>    592            state->lastExceptionStackTrace = (char*)stackTrace;
> (lldb) p state
> (ThreadLocalState *) $0 = 0x0000000000000000
> {noformat}
> The correct way to set CLASSPATH is because libhdfs does not support wildcard 
> in CLASSPATH:
> {noformat}
> $ export CLASSPATH=$(hadoop classpath --glob)
> {noformat}
> Filed HDFS-12491 Support wildcard in CLASSPATH for libhdfs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to