[jira] [Created] (IMPALA-7295) Remove IMPALA_MINICLUSTER_PROFILE=2
Fredy Wijaya created IMPALA-7295: Summary: Remove IMPALA_MINICLUSTER_PROFILE=2 Key: IMPALA-7295 URL: https://issues.apache.org/jira/browse/IMPALA-7295 Project: IMPALA Issue Type: Improvement Components: Infrastructure Affects Versions: Impala 3.0 Reporter: Fredy Wijaya Assignee: Fredy Wijaya -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IMPALA-7294) TABLESAMPLE clause allocates arrays based on total file count instead of selected partitions
Todd Lipcon created IMPALA-7294:
---
Summary: TABLESAMPLE clause allocates arrays based on total file
count instead of selected partitions
Key: IMPALA-7294
URL: https://issues.apache.org/jira/browse/IMPALA-7294
Project: IMPALA
Issue Type: Bug
Affects Versions: Impala 3.0
Reporter: Todd Lipcon
Assignee: Todd Lipcon
The HdfsTable.getFilesSample function takes a list of input partitions to
sample files from, but then, when allocating an array to sample into, sizes
that array based on the total file count across all partitions. This is an
unnecessarily large array, which is expensive to allocate (may cause full GC
when the heap is fragmented). The code claims this to be an optimization:
{code}
// Use max size to avoid looping over inputParts for the exact size.
{code}
...but I think the loop over inputParts is likely to be trivial here since
we'll loop over them anyway later in the function and thus will already be
pulled into CPU cache, etc. This is also necessary for fine-grained metadata
loading in the impalad -- for a large table with many partitions, we don't want
to load the file lists of all partitions just to tablesample from one partition.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IMPALA-7293) Show tuple layout in explain plan
Tim Armstrong created IMPALA-7293:
-
Summary: Show tuple layout in explain plan
Key: IMPALA-7293
URL: https://issues.apache.org/jira/browse/IMPALA-7293
Project: IMPALA
Issue Type: Improvement
Components: Frontend
Reporter: Tim Armstrong
There's currently no way to tell in the explain plan what the contents of each
tuple are. At explain_level>=2 we include "tuple-ids" but no information about
what is actually in the tuples.
{noformat}
[localhost:21000] default> explain select min(regexp_replace(l_comment, ".",
"x"))
from tpch.lineitem; summary;
Query: explain select min(regexp_replace(l_comment, ".", "x"))
from tpch.lineitem
+---+
| Explain String
|
+---+
| Max Per-Host Resource Reservation: Memory=8.00MB Threads=3
|
| Per-Host Resource Estimates: Memory=284.00MB
|
|
|
| F01:PLAN FRAGMENT [UNPARTITIONED] hosts=1 instances=1
|
| | Per-Host Resources: mem-estimate=10.00MB mem-reservation=0B
thread-reservation=1 |
| PLAN-ROOT SINK
|
| | mem-estimate=0B mem-reservation=0B thread-reservation=0
|
| |
|
| 03:AGGREGATE [FINALIZE]
|
| | output: min:merge(regexp_replace(l_comment, '.', 'x'))
|
| | mem-estimate=10.00MB mem-reservation=0B spill-buffer=2.00MB
thread-reservation=0 |
| | tuple-ids=1 row-size=16B cardinality=1
|
| |
|
| 02:EXCHANGE [UNPARTITIONED]
|
| | mem-estimate=0B mem-reservation=0B thread-reservation=0
|
| | tuple-ids=1 row-size=16B cardinality=1
|
| |
|
| F00:PLAN FRAGMENT [RANDOM] hosts=3 instances=3
|
| Per-Host Resources: mem-estimate=274.00MB mem-reservation=8.00MB
thread-reservation=2 |
| 01:AGGREGATE
|
| | output: min(regexp_replace(l_comment, '.', 'x'))
|
| | mem-estimate=10.00MB mem-reservation=0B spill-buffer=2.00MB
thread-reservation=0 |
| | tuple-ids=1 row-size=16B cardinality=1
|
| |
|
| 00:SCAN HDFS [tpch.lineitem, RANDOM]
|
|partitions=1/1 files=1 size=718.94MB
|
|stored statistics:
|
| table: rows=6001215 size=718.94MB
|
| columns: all
|
|extrapolated-rows=disabled max-scan-range-rows=1068457
|
|mem-estimate=264.00MB mem-reservation=8.00MB thread-reservation=1
|
|tuple-ids=0 row-size=42B cardinality=6001215
|
+---+
Fetched 32 row(s) in 0.01s
Summary not available
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IMPALA-7292) Automatically cherry-pick relevant changes from Kudu to Impala
Lars Volker created IMPALA-7292:
---
Summary: Automatically cherry-pick relevant changes from Kudu to
Impala
Key: IMPALA-7292
URL: https://issues.apache.org/jira/browse/IMPALA-7292
Project: IMPALA
Issue Type: Improvement
Components: Backend
Affects Versions: Impala 3.1.0
Reporter: Lars Volker
We should automatically cherry-pick relevant changes from Kudu to Impala. This
should happen for all folders that we share ({{rpc, util, security}}), possibly
also for {{security}}.
[copybara|https://github.com/google/copybara] might be helpful for this.
However, something similar to the Jenkins job that did the master -> 2.x
mirroring might already be enough.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IMPALA-7271) KRPC: cross-port caching of GetLoggedInUser
[ https://issues.apache.org/jira/browse/IMPALA-7271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Volker resolved IMPALA-7271. - Resolution: Fixed Fix Version/s: Impala 3.1.0 Resolved as part of IMPALA-7006 > KRPC: cross-port caching of GetLoggedInUser > --- > > Key: IMPALA-7271 > URL: https://issues.apache.org/jira/browse/IMPALA-7271 > Project: IMPALA > Issue Type: Bug > Components: Backend >Affects Versions: Impala 2.12.0 >Reporter: Todd Lipcon >Assignee: Lars Volker >Priority: Major > Fix For: Impala 3.1.0 > > > In a production cluster I am seeing a high rate of 'mmap' calls under a > workload which starts and stops a lot of exchanges. These are causing a lot > contention for the mmap semaphore, which is then causing page faults to be > rather slow. By running perf record -e syscalls:*mmap I can see that most of > the calls are coming from KRPC's call to GetLoggedInUser when initting a > Proxy object. This was fixed by https://gerrit.cloudera.org/#/c/9895/ which > needs to be cherry-picked over. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IMPALA-7006) Rebase KRPC onto Kudu upstream repository
[ https://issues.apache.org/jira/browse/IMPALA-7006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Volker resolved IMPALA-7006. - Resolution: Fixed Fix Version/s: Impala 3.1.0 > Rebase KRPC onto Kudu upstream repository > - > > Key: IMPALA-7006 > URL: https://issues.apache.org/jira/browse/IMPALA-7006 > Project: IMPALA > Issue Type: Improvement > Components: Backend >Affects Versions: Impala 2.13.0, Impala 3.1.0 >Reporter: Lars Volker >Assignee: Lars Volker >Priority: Major > Labels: krpc > Fix For: Impala 3.1.0 > > > We should consider rebasing our KRPC code on top of the latest Kudu upstream > version. This will keep the two projects more in sync and will allow us to > make use of recent improvements, e.g. around thread stack collection, without > having to pick individual changes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IMPALA-7069) Java UDF tests can trigger a crash in Java ClassLoader
[
https://issues.apache.org/jira/browse/IMPALA-7069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vuk Ercegovac resolved IMPALA-7069.
---
Resolution: Fixed
Fix Version/s: Impala 3.1.0
> Java UDF tests can trigger a crash in Java ClassLoader
> --
>
> Key: IMPALA-7069
> URL: https://issues.apache.org/jira/browse/IMPALA-7069
> Project: IMPALA
> Issue Type: Bug
> Components: Backend
>Affects Versions: Impala 3.1.0
>Reporter: Tim Armstrong
>Assignee: Taras Bobrovytsky
>Priority: Blocker
> Labels: broken-build, crash, flaky
> Fix For: Impala 3.1.0
>
> Attachments: hs_err_pid22764.log, hs_err_pid29246.log,
> hs_err_pid8975.log, hs_err_pid9694.log
>
>
> I hit this crash on a GVO, but was able to reproduce it on master on my
> desktop.
> Repro steps:
> {code}
> git checkout c1362afb9a072e49df470d9068d44cdbdf5cdec5
> ./buildall.sh -debug -noclean -notests -skiptests -ninja
> start-impala-cluster.py
> while impala-py.test tests/query_test/test_udfs.py -k 'hive or java or jar'
> -n4 --verbose; do date; done
> {code}
> I generally hit the crash within a hour of looping the test.
> {noformat}
> Stack: [0x7fa04791f000,0x7fa04812], sp=0x7fa04811aff0, free
> space=8175k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> V [libjvm.so+0x8a8107]
> V [libjvm.so+0x96cf5f]
> v ~RuntimeStub::_complete_monitor_locking_Java
> J 2758 C2
> java.util.concurrent.ConcurrentHashMap.putVal(Ljava/lang/Object;Ljava/lang/Object;Z)Ljava/lang/Object;
> (362 bytes) @ 0x7fa0c73637d4 [0x7fa0c7362d00+0xad4]
> J 2311 C2
> java.lang.ClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class; (122
> bytes) @ 0x7fa0c70a09a8 [0x7fa0c70a08e0+0xc8]
> J 3953 C2
> java.net.FactoryURLClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;
> (40 bytes) @ 0x7fa0c71ce0f0 [0x7fa0c71ce0a0+0x50]
> J 2987 C2
> java.lang.ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class; (7
> bytes) @ 0x7fa0c72ddb64 [0x7fa0c72ddb20+0x44]
> v ~StubRoutines::call_stub
> V [libjvm.so+0x6648eb]
> V [libjvm.so+0x661ec4]
> V [libjvm.so+0x662523]
> V [libjvm.so+0x9e398d]
> V [libjvm.so+0x9e2326]
> V [libjvm.so+0x9e2b50]
> V [libjvm.so+0x42c099]
> V [libjvm.so+0x9dc786]
> V [libjvm.so+0x6a5edf]
> V [libjvm.so+0x6a70cb] JVM_DefineClass+0xbb
> V [libjvm.so+0xa31ea5]
> V [libjvm.so+0xa37ea7]
> J 4842
> sun.misc.Unsafe.defineClass(Ljava/lang/String;[BIILjava/lang/ClassLoader;Ljava/security/ProtectionDomain;)Ljava/lang/Class;
> (0 bytes) @ 0x7fa0c7af120b [0x7fa0c7af1100+0x10b]
> J 13229 C2 sun.reflect.MethodAccessorGenerator$1.run()Ljava/lang/Object; (5
> bytes) @ 0x7fa0c8cf2a74 [0x7fa0c8cf2940+0x134]
> v ~StubRoutines::call_stub
> V [libjvm.so+0x6648eb]
> V [libjvm.so+0x6b5949] JVM_DoPrivileged+0x429
> J 1035
> java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;)Ljava/lang/Object;
> (0 bytes) @ 0x7fa0c7220c7f [0x7fa0c7220bc0+0xbf]
> J 20421 C2
> sun.reflect.MethodAccessorGenerator.generate(Ljava/lang/Class;Ljava/lang/String;[Ljava/lang/Class;Ljava/lang/Class;[Ljava/lang/Class;IZZLjava/lang/Class;)Lsun/reflect/MagicAccessorImpl;
> (762 bytes) @ 0x7fa0c89bb848 [0x7fa0c89b9da0+0x1aa8]
> J 4163 C2
> sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
> (104 bytes) @ 0x7fa0c789cca8 [0x7fa0c789c8c0+0x3e8]
> J 2379 C2 org.apache.impala.hive.executor.UdfExecutor.evaluate()V (396 bytes)
> @ 0x7fa0c711c638 [0x7fa0c711c400+0x238]
> v ~StubRoutines::call_stub
> V [libjvm.so+0x6648eb]
> V [libjvm.so+0x6822d7]
> V [libjvm.so+0x6862c9]
> C [impalad+0x2a004fa] JNIEnv_::CallNonvirtualVoidMethodA(_jobject*,
> _jclass*, _jmethodID*, jvalue const*)+0x40
> C [impalad+0x29fe4ff]
> impala::HiveUdfCall::Evaluate(impala::ScalarExprEvaluator*, impala::TupleRow
> const*) const+0x44b
> C [impalad+0x29ffde9]
> impala::HiveUdfCall::GetSmallIntVal(impala::ScalarExprEvaluator*,
> impala::TupleRow const*) const+0xbb
> C [impalad+0x2a0948a]
> impala::ScalarExprEvaluator::GetValue(impala::ScalarExpr const&,
> impala::TupleRow const*)+0x14c
> C [impalad+0x2a48eb1]
> impala::ScalarFnCall::EvaluateNonConstantChildren(impala::ScalarExprEvaluator*,
> impala::TupleRow const*) const+0x9d
> C [impalad+0x2a4abba] impala_udf::BooleanVal
> impala::ScalarFnCall::InterpretEval(impala::ScalarExprEvaluator*,
> impala::TupleRow const*) const+0x18c
> C [impalad+0x2a4907d]
> impala::ScalarFnCall::GetBooleanVal(impala::ScalarExprEvaluator*,
> impala::TupleRow const*) const+0x179
> C [impalad+0x2a09c7f]
> impala::ScalarExprEvaluator::GetBooleanVal(impala::TupleRow*)+0x37
> C [impalad+0x1b70efb]
[jira] [Created] (IMPALA-7291) [DOCS] Document recommendation to use VARCHAR or STRING instead of CHAR(N)
Balazs Jeszenszky created IMPALA-7291: - Summary: [DOCS] Document recommendation to use VARCHAR or STRING instead of CHAR(N) Key: IMPALA-7291 URL: https://issues.apache.org/jira/browse/IMPALA-7291 Project: IMPALA Issue Type: Improvement Components: Docs Affects Versions: Impala 2.12.0 Reporter: Balazs Jeszenszky CHAR(N) currently does not have codegen support. For that reason, we should recommend customers to use VARCHAR or STRING instead - the gain of codegen outweighs the benefits of fixed width CHARs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IMPALA-7290) Move impala-shell to use HS2
Tim Armstrong created IMPALA-7290: - Summary: Move impala-shell to use HS2 Key: IMPALA-7290 URL: https://issues.apache.org/jira/browse/IMPALA-7290 Project: IMPALA Issue Type: Improvement Components: Clients Reporter: Tim Armstrong Most clients have moved to the HS2 interface. impala-shell is one of the laggards. We should switch impala-shell to use the newer and more standard interface. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IMPALA-7289) Change shell tests to ignore ~/.impalarc
Csaba Ringhofer created IMPALA-7289: --- Summary: Change shell tests to ignore ~/.impalarc Key: IMPALA-7289 URL: https://issues.apache.org/jira/browse/IMPALA-7289 Project: IMPALA Issue Type: Improvement Components: Clients Reporter: Csaba Ringhofer Currently impala-shell always reads a config file ( ~/.impalarc by default), even if it is run during an automatic test. This means that the settings in .impalarc can have side effects during tests - for example if "impalad" is set to remote cluster, the tests will run on that instead of the mini cluster. I see two ways to fix this issue: 1. always set --config_file when running impala-shell during tests to point to somewhere else than ~/.impalarc 2. use an environment variable to affect the config file loading - for example IMPALARC_LOCATION could be set in every test I think that 2 is somewhat better, because it could be done centrally (for example in impala_test_suite.py or impala-py.test), while 1 could not be enforced so easily. A bonus feature for 2 could be to add the possibility of loading more than one config files, for example by setting IMPALARC_LOCATION to a comma separated list of file locations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IMPALA-7278) distinct clause is not working as expected with custom UDFs
[
https://issues.apache.org/jira/browse/IMPALA-7278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Armstrong resolved IMPALA-7278.
---
Resolution: Not A Bug
> distinct clause is not working as expected with custom UDFs
> ---
>
> Key: IMPALA-7278
> URL: https://issues.apache.org/jira/browse/IMPALA-7278
> Project: IMPALA
> Issue Type: Bug
> Components: Frontend
>Affects Versions: Impala 2.8.0
>Reporter: shabnam perween
>Priority: Critical
>
> Distinct clause when executed with custom UDF returns unexpected results.
> Custom UDF Definition:
> udf.h file:
> {code}
> #ifndef IMPALA_UDF_SAMPLE_UDF_H
> #define IMPALA_UDF_SAMPLE_UDF_H
> #include "udf.h"
> using namespace impala_udf;
> #ifdef __cplusplus
> extern "C"
> {
> #endif
> StringVal udf_clear(FunctionContext* context, StringVal& sInput);
> #ifdef __cplusplus
> }
> #endif
> #endif
> {code}
> udf.cpp:
> {code}
> #include "clear.h"
> StringVal udf_clear(
> FunctionContext* context,
> StringVal& sInput /* String to encrypt */
> )
> {
> unsigned char* pReturnData = context->Allocate( 100 );
> memset( pReturnData, NULL, 100);
> memcpy(pReturnData, sInput.ptr, sInput.len );
> StringVal sResult( pReturnData );
> sResult.len = sInput.len;
> context->Free( (uint8_t*)pReturnData );
> return sResult;
> }
> {code}
> CMakeLists.txt:
> {code}
> project (clear)
> ADD_LIBRARY (clear2.8_RHEL SHARED clear.cpp )
> TARGET_LINK_LIBRARIES (clear2.8_RHEL libImpalaUdf.a )
> SET_TARGET_PROPERTIES (clear2.8_RHEL PROPERTIES SUFFIX ".so")
> SET_TARGET_PROPERTIES (clear2.8_RHEL PROPERTIES PREFIX "")
> INSTALL ( TARGETS clear2.8_RHEL DESTINATION . )
> Query Syntax:
> CREATE TABLE clear (c1 STRING, c2 STRING) row format delimited fields
> terminated by ',' stored as textfile;
> LOAD DATA INPATH '/user/clear.csv' OVERWRITE INTO TABLE clear;
> Query: describe clear
> +--++-+
> | name | type | comment |
> +--++-+
> | c1 | string | |
> | c2 | string | |
> +--++-+
> Fetched 2 row(s) in 0.04s
> select * from clear;
> +-+-+
> | c1 | c2 |
> +-+-+
> | 111 | 111 |
> | 111 | 111 |
> | 22 | 22 |
> | 44 | 44 |
> | 22 | 22 |
> | 333 | 333 |
> | 333 | 333 |
> +-+-+
> Fetched 7 row(s) in 0.14s
> select distinct udf_clear(c1),c2 from clear;
> +---+-+
> | default.udf_clear(c1) | c2 |
> +---+-+
> | {color:#d04437}*22* {color}| 44 | <== this should be *44*
> | 22 | 22 |
> | 333 | 333 |
> | 111 | 111 |
> +---+-+
> Fetched 4 row(s) in 0.24s
> {code}
>
> Expected result:
> {code}
> select distinct c1,c2 from clear;
> +-+-+
> | c1 | c2 |
> +-+-+
> | 44 | 44 |
> | 22 | 22 |
> | 333 | 333 |
> | 111 | 111 |
> +-+-+
> Fetched 4 row(s) in 0.25s
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IMPALA-7275) Create table with insufficient privileges should not show table
[
https://issues.apache.org/jira/browse/IMPALA-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holley resolved IMPALA-7275.
-
Resolution: Fixed
Fix Version/s: Impala 3.1.0
> Create table with insufficient privileges should not show table
> ---
>
> Key: IMPALA-7275
> URL: https://issues.apache.org/jira/browse/IMPALA-7275
> Project: IMPALA
> Issue Type: Bug
> Components: Frontend
>Affects Versions: Impala 3.0
>Reporter: Adam Holley
>Assignee: Adam Holley
>Priority: Major
> Labels: security
> Fix For: Impala 3.1.0
>
>
> {noformat}
> [localhost:21000] default> create table db1.tbl1;
> Query: create table db1.tbl
> ERROR: AuthorizationException: User 'user1' does not have privileges to
> execute 'CREATE' on: db1.tbl1
> {noformat}
> The error message should be:
> ERROR: AuthorizationException: User 'user1' does not have privileges to
> execute 'CREATE' on: db1
> Note that it is not permitted to have CREATE granted to a table.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IMPALA-7288) Codegen crash in FinalizeModule()
Balazs Jeszenszky created IMPALA-7288:
-
Summary: Codegen crash in FinalizeModule()
Key: IMPALA-7288
URL: https://issues.apache.org/jira/browse/IMPALA-7288
Project: IMPALA
Issue Type: Bug
Components: Backend
Affects Versions: Impala 2.12.0
Reporter: Balazs Jeszenszky
The following sequence crashes Impala 2.12 reliably:
{code}
CREATE TABLE test (c1 CHAR(6),c2 CHAR(6));
select 1 from test t1, test t2
where t1.c1 = FROM_TIMESTAMP(cast(t2.c2 as string), 'MMdd');
{code}
hs_err_pid has:
{code}
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x03b36ce4, pid=28459, tid=0x7f2c49685700
#
# JRE version: Java(TM) SE Runtime Environment (8.0_162-b12) (build
1.8.0_162-b12)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.162-b12 mixed mode linux-amd64
compressed oops)
# Problematic frame:
# C [impalad+0x3736ce4] llvm::Value::getContext() const+0x4
{code}
Backtrace is:
{code}
#0 0x7f2cb217a5f7 in raise () from /lib64/libc.so.6
#1 0x7f2cb217bce8 in abort () from /lib64/libc.so.6
#2 0x7f2cb4de2f35 in os::abort(bool) () from
/usr/java/latest/jre/lib/amd64/server/libjvm.so
#3 0x7f2cb4f86f33 in VMError::report_and_die() () from
/usr/java/latest/jre/lib/amd64/server/libjvm.so
#4 0x7f2cb4de922f in JVM_handle_linux_signal () from
/usr/java/latest/jre/lib/amd64/server/libjvm.so
#5 0x7f2cb4ddf253 in signalHandler(int, siginfo*, void*) () from
/usr/java/latest/jre/lib/amd64/server/libjvm.so
#6
#7 0x03b36ce4 in llvm::Value::getContext() const ()
#8 0x03b36cff in llvm::Value::getValueName() const ()
#9 0x03b36de9 in llvm::Value::getName() const ()
#10 0x01ba6bb2 in impala::LlvmCodeGen::FinalizeModule (this=0x9b53980)
at
/usr/src/debug/impala-2.12.0-cdh5.15.0/be/src/codegen/llvm-codegen.cc:1076
#11 0x018f5c0f in impala::FragmentInstanceState::Open (this=0xac0b400)
at
/usr/src/debug/impala-2.12.0-cdh5.15.0/be/src/runtime/fragment-instance-state.cc:255
#12 0x018f3699 in impala::FragmentInstanceState::Exec (this=0xac0b400)
at
/usr/src/debug/impala-2.12.0-cdh5.15.0/be/src/runtime/fragment-instance-state.cc:80
#13 0x019028c3 in impala::QueryState::ExecFInstance (this=0x9c6ad00,
fis=0xac0b400)
at /usr/src/debug/impala-2.12.0-cdh5.15.0/be/src/runtime/query-state.cc:410
#14 0x0190113c in impala::QueryStateoperator()(void)
const (__closure=0x7f2c49684be8)
at /usr/src/debug/impala-2.12.0-cdh5.15.0/be/src/runtime/query-state.cc:350
#15 0x019034dd in
boost::detail::function::void_function_obj_invoker0,
void>::invoke(boost::detail::function::function_buffer &)
(function_obj_ptr=...)
at
/usr/src/debug/impala-2.12.0-cdh5.15.0/toolchain/boost-1.57.0-p3/include/boost/function/function_template.hpp:153
{code}
Crash is at
https://github.com/cloudera/Impala/blob/cdh5-2.12.0_5.15.0/be/src/codegen/llvm-codegen.cc#L1070-L1079.
The repro steps seem to be quite specific.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IMPALA-7287) Speed up printing of tab delimited output in impala-shell
Csaba Ringhofer created IMPALA-7287: --- Summary: Speed up printing of tab delimited output in impala-shell Key: IMPALA-7287 URL: https://issues.apache.org/jira/browse/IMPALA-7287 Project: IMPALA Issue Type: Improvement Reporter: Csaba Ringhofer Beeswax returns result rows as strings where the columns are separated by tab characters. ImpalaClient.fetch() splits the rows and printing functions join them again. If the output_delimiter is \t, and the row doesn't contain any special characters, then the result is exactly the same string that was fetched. As \t is the default delimiter, I think that it would be useful to create a "fast path" for this special case. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IMPALA-7286) Command "unset" does not work for shell options
Csaba Ringhofer created IMPALA-7286: --- Summary: Command "unset" does not work for shell options Key: IMPALA-7286 URL: https://issues.apache.org/jira/browse/IMPALA-7286 Project: IMPALA Issue Type: Bug Components: Clients Reporter: Csaba Ringhofer "unset LIVE_PROGRESS;" does not unset LIVE_PROGRESS and leads to the following error message: No option called LIVE_PROGRESS is set I think that unset should work for shell options too for the sake of consistency. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
