[jira] [Created] (IMPALA-6218) Crash due to memory allocation failure on secure cluster

[Mostafa Mokhtar (JIRA)]

Mostafa Mokhtar created IMPALA-6218:
---

 Summary: Crash due to memory allocation failure on secure cluster
 Key: IMPALA-6218
 URL: https://issues.apache.org/jira/browse/IMPALA-6218
 Project: IMPALA
  Issue Type: Bug
  Components: Backend
Affects Versions: Impala 2.11.0
Reporter: Mostafa Mokhtar
Priority: Blocker


When running 16 concurrent TPCDS queries on a 7 node secure cluster, this crash 
occurred. 
Memory was not oversubscribed on the host. 

{code}
#0  0x003c49632625 in raise () from /lib64/libc.so.6
#1  0x003c49633e05 in abort () from /lib64/libc.so.6
#2  0x03bb9bd4 in ?? ()
#3  0x03bb064d in google::LogMessage::Fail() ()
#4  0x03bb1ef2 in google::LogMessage::SendToLog() ()
#5  0x03bb0027 in google::LogMessage::Flush() ()
#6  0x03bb35ee in google::LogMessageFatal::~LogMessageFatal() ()
#7  0x01b03d2f in ?? ()
#8  0x03ada85a in llvm::report_fatal_error(llvm::Twine const&, bool) ()
#9  0x03adaa1c in llvm::report_fatal_error(char const*, bool) ()
#10 0x038b2902 in 
llvm::RuntimeDyldImpl::emitSection(llvm::object::ObjectFile const&, 
llvm::object::SectionRef const&, bool) ()
#11 0x038b2d7c in 
llvm::RuntimeDyldImpl::findOrEmitSection(llvm::object::ObjectFile const&, 
llvm::object::SectionRef const&, bool, std::map >&) ()
#12 0x038b3e35 in 
llvm::RuntimeDyldImpl::loadObjectImpl(llvm::object::ObjectFile const&) ()
#13 0x038c9f47 in 
llvm::RuntimeDyldELF::loadObject(llvm::object::ObjectFile const&) ()
#14 0x038afc20 in 
llvm::RuntimeDyld::loadObject(llvm::object::ObjectFile const&) ()
#15 0x0372d3fa in llvm::MCJIT::generateCodeForModule(llvm::Module*) ()
#16 0x03729b10 in llvm::MCJIT::finalizeObject() ()
#17 0x01b0dc16 in impala::LlvmCodeGen::FinalizeModule() ()
#18 0x0189c254 in impala::FragmentInstanceState::Open() ()
#19 0x01899e7b in impala::FragmentInstanceState::Exec() ()
#20 0x018847fe in 
impala::QueryState::ExecFInstance(impala::FragmentInstanceState*) ()
#21 0x018830c0 in ?? ()
---Type  to continue, or q  to quit---
#22 0x01885449 in ?? ()
#23 0x017b048a in boost::function0::operator()() const ()
#24 0x01ab4ab1 in 
impala::Thread::SuperviseThread(std::basic_string const&, std::basic_string const&, boost::function, 
impala::Promise*) ()
#25 0x01abd63c in void 
boost::_bi::list4 >, 
boost::_bi::value >, boost::_bi::value, 
boost::_bi::value >::operator(), std::allocator > 
const&, std::basic_string 
const&, boost::function, impala::Promise*), 
boost::_bi::list0>(boost::_bi::type, void (*&)(std::basic_string const&, std::basic_string const&, boost::function, impala::Promise*), boost::_bi::list0&, int) ()
#26 0x01abd57f in boost::_bi::bind_t 
const&, std::basic_string 
const&, boost::function, impala::Promise*), 
boost::_bi::list4 >, 
boost::_bi::value >, boost::_bi::value, 
boost::_bi::value > >::operator()() ()
#27 0x01abd542 in boost::detail::thread_data 
const&, std::basic_string 
const&, boost::function, impala::Promise*), 
boost::_bi::list4 >, 
boost::_bi::value >, boost::_bi::value, 
boost::_bi::value > > >::run() ()
#28 0x02d3a09a in ?? ()
#29 0x003c49a07aa1 in start_thread () from /lib64/libpthread.so.0
#30 0x003c496e893d in clone () from /lib64/libc.so.6
{code}



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

[jira] [Created] (IMPALA-6216) PYTHON_EGG_CACHE used in impala-shell code should be made configurable

[Mala Chikka Kempanna (JIRA)]

Mala Chikka Kempanna created IMPALA-6216:


 Summary: PYTHON_EGG_CACHE used in impala-shell code should be made 
configurable
 Key: IMPALA-6216
 URL: https://issues.apache.org/jira/browse/IMPALA-6216
 Project: IMPALA
  Issue Type: Bug
Reporter: Mala Chikka Kempanna



Reference : 
https://github.com/cloudera/Impala/blob/f2d414093df3f5c1b65512fa82682308ae33edb2/shell/impala-shell#L40

This line in impala-shell sets python egg cache to /tmp path.
{code}
PYTHON_EGG_CACHE=/tmp/impala-shell-python-egg-cache-${USER}
{code}

Not all users want to give exec permission on /tmp directory for security 
reasons.
Hence, please make this configurable.



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

[jira] [Created] (IMPALA-6215) Race between lib_cache and java udf class loading

[Vuk Ercegovac (JIRA)]

Vuk Ercegovac created IMPALA-6215:
-

 Summary: Race between lib_cache and java udf class loading
 Key: IMPALA-6215
 URL: https://issues.apache.org/jira/browse/IMPALA-6215
 Project: IMPALA
  Issue Type: Bug
Reporter: Vuk Ercegovac


There's a race between the lib_cache (backend) and UdfExecutor's class loading 
(frontend).

A sequence of events that exposes this race is as follows:

1. Backend hive-udf-call, in Init obtains the cached, local path to the jar 
containing the java
method to run
2. A function that is contained in the cached jar is dropped
3. The impala server, on a separate thread learns of the dropped function, so 
blows away the
containing jar
4. Backend hive-udf-call is opened, which constructs the UdfExecutor given the 
cached path
to the jar that has just been deleted. A classloader is created with that 
path-- when the 
class is resolved, we get a ClassNotFound exception

An example of this sequence shows up occasionally and is the reason for the 
following flake: 
https://issues.apache.org/jira/browse/IMPALA-6092



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