Support Questions
Find answers, ask questions, and share your expertise
Announcements
Alert: Welcome to the Unified Cloudera Community. Former HCC members be sure to read and learn how to activate your account here.

Impala UDF in C++ : impala-shell returns " Error communicating with impalad: TSocket read 0 bytes"

Impala UDF in C++ : impala-shell returns " Error communicating with impalad: TSocket read 0 bytes"

Explorer

when I'm running a select query with UDF which has boost regex matching check, impala-shell crashes and returns error message  " Error communicating with impalad: TSocket read 0 bytes"

 

in this udf the input string will be compared with a reg-ex using boost regex library and it will return string value 'Y' or 'N' .

 

I'm sharing the error log file /var/run/cloudera-scm-agent/process/1047-impala-IMPALAD/hs_err_pid6574.log 

 

https://drive.google.com/file/d/0BxU8RoPuGRB5eTMtTGhKWG9BbVE/view?usp=sharing

 

and info about impala can find in this link..

 

https://drive.google.com/file/d/0BxU8RoPuGRB5OVkzT3p0cUlaT1U/view?usp=sharing     (please download html file and open in browser).

 

Can anyone suggest what went wrong here and what is the fix for this?

1 REPLY 1
Highlighted

Re: Impala UDF in C++ : impala-shell returns " Error communicating with impalad: TSocket read 0

Cloudera Employee

The key part of the error is indicated here:

 

#  SIGSEGV (0xb) at pc=0x0000000000b7b623, pid=6574, tid=140376947717888
#
# JRE version: Java(TM) SE Runtime Environment (8.0_60-b27) (build 1.8.0_60-b27)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.60-b23 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  [impalad+0x77b623]  boost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::~perl_matcher()+0x53

 

It's unclear from the output whether the problem is related to Impala or the C++ function of the UDF itself. It appears to be the latter. To understand the problem, please enable coredumping by doing "ulimit -c unlimited" and once the core file is located, do gdb -c <core-file> <impalad>.