2 observations from running both the v0505 build, and a v0505+UTT build that is supposed to stop sending CQDs to the compilers (which was originally thought to be the root cause of this problem):
(1) The problem of CATALOG_NAME 4033 error and the core may be 2 different problems, even though they often appear on the same statement. The cores have been seen several times on the v0505 build, as well as the v0505+UTT build.
(2) The situation has gotten worse with the v0505 build. We now are seeing this core even with an update statement:
SQL>update M set(vch7,nint) =(select vch7,nint from ttf1 where nint=5) where (nsint=1);
*** ERROR[1] The message id: problem_with_server_read
*** ERROR[1] The message id: header_not_long_enough
*** ERROR[1] The message id: problem_with_server_read
*** ERROR[1] The message id: header_not_long_enough
(gdb) bt
#0 0x00007ffff4a3d625 in raise () from /lib64/libc.so.6
#1 0x00007ffff4a3ed8d in abort () from /lib64/libc.so.6
#2 0x00007ffff5b48c55 in os::abort(bool) ()
from /usr/java/jdk1.7.0_75/jre/lib/amd64/server/libjvm.so
#3 0x00007ffff5ccacd7 in VMError::report_and_die() ()
from /usr/java/jdk1.7.0_75/jre/lib/amd64/server/libjvm.so
#4 0x00007ffff5b4db6f in JVM_handle_linux_signal ()
from /usr/java/jdk1.7.0_75/jre/lib/amd64/server/libjvm.so
#5 <signal handler called>
#6 0x00007ffff2df0b99 in ExHbaseAccessTcb::setupUniqueKeyAndCols (
this=0x7fffd273d5a0, doInit=0) at ../executor/ExHbaseAccess.cpp:1690
#7 0x00007ffff2e024a1 in ExHbaseAccessSQRowsetTcb::work (this=0x7fffd273d5a0)
at ../executor/ExHbaseIUD.cpp:3674
#8 0x00007ffff2e20d03 in ExScheduler::work (this=0x7fffd273b138,
prevWaitTime=<optimized out>) at ../executor/ExScheduler.cpp:328
#9 0x00007ffff2d46732 in ex_root_tcb::execute (this=0x7fffd273f0f0,
cliGlobals=0xee7250, glob=0x7fffd2777af0, input_desc=0x7fffd278d160,
diagsArea=@0x7fffe519bb10: 0x0, reExecute=0)
at ../executor/ex_root.cpp:1055
#10 0x00007ffff43744e4 in CliStatement::execute (this=0x7fffc6b34330,
cliGlobals=0xee7250, input_desc=0x7fffd278d160, diagsArea=...,
execute_state=<optimized out>, fixupOnly=0, cliflags=0)
at ../cli/Statement.cpp:4558
#11 0x00007ffff431b14c in SQLCLI_PerformTasks(CliGlobals *, ULng32, SQLSTMT_ID *, SQLDESC_ID *, SQLDESC_ID *, Lng32, Lng32, typedef __va_list_tag __va_list_tag *, SQLCLI_PTR_PAIRS *, SQLCLI_PTR_PAIRS *) (cliGlobals=0xee7250, tasks=8063,
statement_id=0x9f10ba8, input_descriptor=0x9f10bd8, output_descriptor=0x0,
num_input_ptr_pairs=0, num_output_ptr_pairs=0, ap=0x7fffe519bcb0,
input_ptr_pairs=0x0, output_ptr_pairs=0x0) at ../cli/Cli.cpp:3285
#12 0x00007ffff4381209 in SQL_EXEC_ClearExecFetchClose (
statement_id=0x9f10ba8, input_descriptor=0x9f10bd8, output_descriptor=0x0,
num_input_ptr_pairs=0, num_output_ptr_pairs=0, num_total_ptr_pairs=0)
at ../cli/CliExtern.cpp:2627
#13 0x00007ffff686e29f in SRVR::WSQL_EXEC_ClearExecFetchClose (
statement_id=0x9f10ba8, input_descriptor=<optimized out>,
output_descriptor=<optimized out>, num_input_ptr_pairs=<optimized out>,
num_output_ptr_pairs=<optimized out>, num_total_ptr_pairs=<optimized out>)
at SQLWrapper.cpp:459
#14 0x00007ffff68648b2 in SRVR::EXECUTE2 (pSrvrStmt=0x9f10590)
at sqlinterface.cpp:5542
#15 0x00007ffff689550e in odbc_SQLSvc_Execute2_sme_ (objtag_=<optimized out>,
call_id_=<optimized out>, dialogueId=<optimized out>,
sqlAsyncEnable=<optimized out>, queryTimeout=<optimized out>,
inputRowCnt=<optimized out>, sqlStmtType=2, stmtHandle=166790544,
cursorLength=0, cursorName=0x0, cursorCharset=1, holdableCursor=0,
inValuesLength=0, inValues=0x0, returnCode=0x7fffe519c5a8,
sqlWarningOrErrorLength=0x7fffe519c5a4,
sqlWarningOrError=@0x7fffe519c580: 0x0, rowsAffected=0x7fffe519c5a0,
outValuesLength=0x7fffe519c594, outValues=@0x7fffe519c578: 0x0)
at srvrothers.cpp:1527
#16 0x00000000004c5442 in odbc_SQLSrvr_ExecDirect_ame_ (objtag_=0x9bae840,
call_id_=0x9bae898, dialogueId=598979694, stmtLabel=<optimized out>,
cursorName=0x0, stmtExplainLabel=<optimized out>, stmtType=0,
sqlStmtType=2,
sqlString=0xa046494 "update M set(vch7,nint) =(select vch7,nint from ttf1 where nint=5) where (nsint=1)", sqlAsyncEnable=0, queryTimeout=0, inputRowCnt=0,
txnID=0, holdableCursor=0) at SrvrConnect.cpp:7895
#17 0x0000000000493bf6 in SQLEXECUTE_IOMessage (objtag_=0x9bae840,
call_id_=0x9bae898, operation_id=3012) at Interface/odbcs_srvr.cpp:1728
#18 0x0000000000493ca4 in DISPATCH_TCPIPRequest (objtag_=0x9bae840,
call_id_=0x9bae898, operation_id=<optimized out>)
at Interface/odbcs_srvr.cpp:1793
#19 0x0000000000433972 in BUILD_TCPIP_REQUEST (pnode=0x9bae840)
at ../Common/TCPIPSystemSrvr.cpp:603
#20 0x000000000043430d in PROCESS_TCPIP_REQUEST (pnode=0x9bae840)
at ../Common/TCPIPSystemSrvr.cpp:581
#21 0x00000000004624f6 in CNSKListenerSrvr::tcpip_listener (arg=0xda2ab0)
at Interface/linux/Listener_srvr_ps.cpp:400
#22 0x00007ffff47f1300 in sb_thread_sthr_disp (pp_arg=0xeb1ec0)
at threadl.cpp:253
#23 0x00007ffff45bd9d1 in start_thread () from /lib64/libpthread.so.0
#24 0x00007ffff4af38fd in clone () from /lib64/libc.so.6
(gdb)
2 observations from running both the v0505 build, and a v0505+UTT build that is supposed to stop sending CQDs to the compilers (which was originally thought to be the root cause of this problem):
(1) The problem of CATALOG_NAME 4033 error and the core may be 2 different problems, even though they often appear on the same statement. The cores have been seen several times on the v0505 build, as well as the v0505+UTT build.
(2) The situation has gotten worse with the v0505 build. We now are seeing this core even with an update statement:
SQL>update M set(vch7,nint) =(select vch7,nint from ttf1 where nint=5) where (nsint=1); with_server_ read not_long_ enough with_server_ read not_long_ enough
*** ERROR[1] The message id: problem_
*** ERROR[1] The message id: header_
*** ERROR[1] The message id: problem_
*** ERROR[1] The message id: header_
(gdb) bt jdk1.7. 0_75/jre/ lib/amd64/ server/ libjvm. so :report_ and_die( ) () jdk1.7. 0_75/jre/ lib/amd64/ server/ libjvm. so linux_signal () jdk1.7. 0_75/jre/ lib/amd64/ server/ libjvm. so b::setupUniqueK eyAndCols ( 0x7fffd273d5a0, doInit=0) at ../executor/ ExHbaseAccess. cpp:1690 RowsetTcb: :work (this=0x7fffd27 3d5a0) ExHbaseIUD. cpp:3674 3b138, e=<optimized out>) at ../executor/ ExScheduler. cpp:328 tcb::execute (this=0x7fffd27 3f0f0, 0xee7250, glob=0x7fffd277 7af0, input_desc= 0x7fffd278d160, @0x7fffe519bb10 : 0x0, reExecute=0) ex_root. cpp:1055 :execute (this=0x7fffc6b 34330, 0xee7250, input_desc= 0x7fffd278d160, diagsArea=..., state=< optimized out>, fixupOnly=0, cliflags=0) Statement. cpp:4558 PerformTasks( CliGlobals *, ULng32, SQLSTMT_ID *, SQLDESC_ID *, SQLDESC_ID *, Lng32, Lng32, typedef __va_list_tag __va_list_tag *, SQLCLI_PTR_PAIRS *, SQLCLI_PTR_PAIRS *) (cliGlobals= 0xee7250, tasks=8063, id=0x9f10ba8, input_descripto r=0x9f10bd8, output_ descriptor= 0x0, input_ptr_ pairs=0, num_output_ ptr_pairs= 0, ap=0x7fffe519bcb0, ptr_pairs= 0x0, output_ ptr_pairs= 0x0) at ../cli/Cli.cpp:3285 ClearExecFetchC lose ( id=0x9f10ba8, input_descripto r=0x9f10bd8, output_ descriptor= 0x0, input_ptr_ pairs=0, num_output_ ptr_pairs= 0, num_total_ ptr_pairs= 0) CliExtern. cpp:2627 EXEC_ClearExecF etchClose ( id=0x9f10ba8, input_descripto r=<optimized out>, descriptor= <optimized out>, num_input_ ptr_pairs= <optimized out>, output_ ptr_pairs= <optimized out>, num_total_ ptr_pairs= <optimized out>) 0x9f10590) cpp:5542 Execute2_ sme_ (objtag_=<optimized out>, id_=<optimized out>, dialogueId= <optimized out>, ble=<optimized out>, queryTimeout= <optimized out>, =<optimized out>, sqlStmtType=2, stmtHandle= 166790544, gth=0, inValues=0x0, returnCode= 0x7fffe519c5a8, rErrorLength= 0x7fffe519c5a4, rError= @0x7fffe519c580 : 0x0, rowsAffected= 0x7fffe519c5a0, ngth=0x7fffe519 c594, outValues= @0x7fffe519c578 : 0x0) ExecDirect_ ame_ (objtag_=0x9bae840, id_=0x9bae898, dialogueId= 598979694, stmtLabel= <optimized out>, l=<optimized out>, stmtType=0, 0xa046494 "update M set(vch7,nint) =(select vch7,nint from ttf1 where nint=5) where (nsint=1)", sqlAsyncEnable=0, queryTimeout=0, inputRowCnt=0, cpp:7895 IOMessage (objtag_=0x9bae840, id_=0x9bae898, operation_id=3012) at Interface/ odbcs_srvr. cpp:1728 TCPIPRequest (objtag_=0x9bae840, id_=0x9bae898, operation_ id=<optimized out>) odbcs_srvr. cpp:1793 TCPIPSystemSrvr .cpp:603 TCPIP_REQUEST (pnode=0x9bae840) TCPIPSystemSrvr .cpp:581 r::tcpip_ listener (arg=0xda2ab0) linux/Listener_ srvr_ps. cpp:400 libpthread. so.0
#0 0x00007ffff4a3d625 in raise () from /lib64/libc.so.6
#1 0x00007ffff4a3ed8d in abort () from /lib64/libc.so.6
#2 0x00007ffff5b48c55 in os::abort(bool) ()
from /usr/java/
#3 0x00007ffff5ccacd7 in VMError:
from /usr/java/
#4 0x00007ffff5b4db6f in JVM_handle_
from /usr/java/
#5 <signal handler called>
#6 0x00007ffff2df0b99 in ExHbaseAccessTc
this=
#7 0x00007ffff2e024a1 in ExHbaseAccessSQ
at ../executor/
#8 0x00007ffff2e20d03 in ExScheduler::work (this=0x7fffd27
prevWaitTim
#9 0x00007ffff2d46732 in ex_root_
cliGlobals=
diagsArea=
at ../executor/
#10 0x00007ffff43744e4 in CliStatement:
cliGlobals=
execute_
at ../cli/
#11 0x00007ffff431b14c in SQLCLI_
statement_
num_
input_
#12 0x00007ffff4381209 in SQL_EXEC_
statement_
num_
at ../cli/
#13 0x00007ffff686e29f in SRVR::WSQL_
statement_
output_
num_
at SQLWrapper.cpp:459
#14 0x00007ffff68648b2 in SRVR::EXECUTE2 (pSrvrStmt=
at sqlinterface.
#15 0x00007ffff689550e in odbc_SQLSvc_
call_
sqlAsyncEna
inputRowCnt
cursorLength=0, cursorName=0x0, cursorCharset=1, holdableCursor=0,
inValuesLen
sqlWarningO
sqlWarningO
outValuesLe
at srvrothers.cpp:1527
#16 0x00000000004c5442 in odbc_SQLSrvr_
call_
cursorName=0x0, stmtExplainLabe
sqlStmtType=2,
sqlString=
txnID=0, holdableCursor=0) at SrvrConnect.
#17 0x0000000000493bf6 in SQLEXECUTE_
call_
#18 0x0000000000493ca4 in DISPATCH_
call_
at Interface/
#19 0x0000000000433972 in BUILD_TCPIP_REQUEST (pnode=0x9bae840)
at ../Common/
#20 0x000000000043430d in PROCESS_
at ../Common/
#21 0x00000000004624f6 in CNSKListenerSrv
at Interface/
#22 0x00007ffff47f1300 in sb_thread_sthr_disp (pp_arg=0xeb1ec0)
at threadl.cpp:253
#23 0x00007ffff45bd9d1 in start_thread () from /lib64/
#24 0x00007ffff4af38fd in clone () from /lib64/libc.so.6
(gdb)