Phoenix tests run into several error 8810 when other tests are run in parallel with it
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Trafodion |
Triaged
|
High
|
Justin Du |
Bug Description
Running phoenix and jdbc catalog api tests at the same time resulted in 16 failures in phoenix with error 8810, during ddl operations as shown below. All the jdbc catalog api tests passed.
Phoenix runs fine when no other tests are running on the system.
test.java.
....*** ERROR[8810] Executor ran into an internal failure and returned an error without populating the diagnostics area. This error is being injected to indicate that. [2015-01-22 08:32:31]
E.E.............
Time: 701.811
There were 2 failures:
1) testKeyProjecti
java.lang.
at org.junit.
at test.java.
at test.java.
On Justin's sugegstion, added ABORT_ON_ERROR for 8810 and the core has this stack:
#0 0x00007ffff4a458a5 in raise () from /lib64/libc.so.6
#1 0x00007ffff4a4700d in abort () from /lib64/libc.so.6
#2 0x00007ffff1248114 in ComCondition:
this=<value optimized out>, newSQLCODE=-8810)
at ../export/
#3 0x00007ffff3f66e36 in operator<< (d=..., dgObj=...)
at ../common/
#4 0x00007ffff437e4e3 in CliStatement::fetch (this=<value optimized out>,
cliGlobals=
newOperation=1) at ../cli/
#5 0x00007ffff4324e0f in SQLCLI_
statement_
num_
input_
#6 0x00007ffff438a40b in SQL_EXEC_
statement_
num_
at ../cli/
#7 0x00007ffff68703bf in SRVR::WSQL_
statement_
output_
num_
num_
num_
#8 0x00007ffff6866cff in SRVR::EXECUTE2 (pSrvrStmt=
at sqlinterface.
#9 0x00007ffff689733e in odbc_SQLSvc_
objtag_=<value optimized out>, call_id_=<value optimized out>,
dialogueId=
---Type <return> to continue, or q <return> to quit---
queryTimeou
sqlStmtType
cursorChars
returnCode=
sqlWarningO
outValuesLe
at srvrothers.cpp:1517
#10 0x00000000004cbc42 in odbc_SQLSrvr_
call_
stmtLabel=
stmtExplain
sqlString=
sqlAsyncEna
at SrvrConnect.
#11 0x0000000000494086 in SQLEXECUTE_
call_
#12 0x0000000000494134 in DISPATCH_
call_
at Interface/
#13 0x0000000000433822 in BUILD_TCPIP_REQUEST (pnode=0x24a84d0)
at ../Common/
#14 0x00000000004341bd in PROCESS_
at ../Common/
#15 0x0000000000462396 in CNSKListenerSrv
at Interface/
#16 0x00007ffff47f9290 in sb_thread_sthr_disp (pp_arg=0xeb5490)
at threadl.cpp:253
#17 0x00007ffff45c5851 in start_thread () from /lib64/
#18 0x00007ffff4afb90d in clone () from /lib64/libc.so.6
(gdb)
Changed in trafodion: | |
importance: | Undecided → High |
assignee: | nobody → Justin Du (justin-du-2) |
milestone: | none → r1.1 |
Changed in trafodion: | |
status: | New → In Progress |
Changed in trafodion: | |
status: | In Progress → Triaged |
Changed in trafodion: | |
milestone: | r1.1 → r1.2 |
The query uses ExDDLTcb::work() method, which calls CmpContext: :compileDirect( ). It is possible that compileDirect() returned with failure without populating the diagsArea.
Also, the failure seems transient.
Could add code in CmpContext: :compieDirect( ) to check the diagsArea at failure case.