Hi folks, I'm debugging some test failures related to an LLVM/AvroCodegen patch I've got going on. The failures are in the parallel EE tests, and most of them are complaining that Impala is out to lunch. It looks like the following assertion is firing, causing an impalad to fail, causing many tests to start failing. (I've also got a minidump, but the build was on jenkins.impala.io, so I don't think I have the symbols/binaries to use it.)
If this sort of thing rings a bell for anyone, please holler! Obviously I'll work on reproducing this locally to figure it out. F1025 02:20:43.786911 82485 mem-tracker.h:231] Check failed: tracker->consumption_->current_value() >= 0 (-1052615 vs. 0) Runtime Filter (Coordinator): Total=-1.00 MB Peak=1.00 MB *** Check failure stack trace: *** @ 0x2f1e11d google::LogMessage::Fail() @ 0x2f1f9c2 google::LogMessage::SendToLog() @ 0x2f1daf7 google::LogMessage::Flush() @ 0x2f210be google::LogMessageFatal::~LogMessageFatal() @ 0x17425fb impala::MemTracker::Release() @ 0x1fa7e8b impala::Coordinator::UpdateFilter() @ 0x186e3cf impala::ImpalaServer::UpdateFilter() @ 0x18d824f impala::ImpalaInternalService::UpdateFilter() @ 0x1dda35a impala::ImpalaInternalServiceProcessor::process_UpdateFilter() @ 0x1dd8308 impala::ImpalaInternalServiceProcessor::dispatchCall() @ 0x15410ea apache::thrift::TDispatchProcessor::process() @ 0x171042b apache::thrift::server::TAcceptQueueServer::Task::run() @ 0x170c307 impala::ThriftThread::RunRunnable() @ 0x170da13 boost::_mfi::mf2<>::operator()() @ 0x170d8a9 boost::_bi::list3<>::operator()<>() @ 0x170d5f5 boost::_bi::bind_t<>::operator()() @ 0x170d508 boost::detail::function::void_function_obj_invoker0<>::invoke() @ 0x171bdfc boost::function0<>::operator()() @ 0x19f3393 impala::Thread::SuperviseThread() @ 0x19fbf26 boost::_bi::list4<>::operator()<>() @ 0x19fbe69 boost::_bi::bind_t<>::operator()() @ 0x19fbe2c boost::detail::thread_data<>::run() @ 0x20a7c9a thread_proxy @ 0x7fe6536186ba start_thread @ 0x7fe65334e3dd clone r.java:81)