[ https://issues.apache.org/jira/browse/HDFS-4831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13659990#comment-13659990 ]
Colin Patrick McCabe commented on HDFS-4831: -------------------------------------------- It's interesting that this is coming up only for {{libhdfs}} users. My guess is that when you launch a standalone JVM, it sets up a signal handler that ignores {{SIGPIPE}}, but JNI code does not get this same benefit. One way to fix this is modify your program which uses {{libhdfs}} to call this prior to initializing {{JNI}}: {code} signal(SIGPIPE, SIG_IGN); {code} This ignores the {{SIGPIPE}} signal whenever it happens. When you initialize JNI, it creates its own signal handlers, which will call the previously installed signal handler if it was explicitly set (i.e., is not the default). However, this is kind of a hack. We shouldn't expect {{libhdfs}} users to have to jump through these kind of hoops. The best fix is to use {{MSG_NOSIGNAL}} or {{MSG_NOSIGPIPE}} to avoid generating these signals in the first place. > Performing direct read using libhdfs sometimes raises SIGPIPE (which in turn > throws SIGABRT) causing client crashes > ------------------------------------------------------------------------------------------------------------------- > > Key: HDFS-4831 > URL: https://issues.apache.org/jira/browse/HDFS-4831 > Project: Hadoop HDFS > Issue Type: Bug > Components: libhdfs > Affects Versions: 2.0.4-alpha > Reporter: Lenni Kuff > > Reading using libhdfs sometimes raises SIGPIPE (which in turn throws SIGABRT > from JVM_handle_linux_signal). This can lead to crashes in the client > application. It would be nice if libhdfs handled this signal internally. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira