T2 Phoenix tests creating cores at CliStatement::doOltExecute
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Trafodion |
Fix Committed
|
High
|
Weiqing Xu |
Bug Description
These T2 phoenix tests are dumping core from 3/29 build. Stack trace is below.
ProductMetricsTest
QueryExecTest
VariableLengthP
We are also seeing errors such as this from other tests (which are not coring), which are also date/time related:
java.sql.
at org.trafodion.
at org.trafodion.
at test.java.
at test.java.
test.java.
*** ERROR[20123] A user-defined transaction has been started. This DDL operation cannot be performed.
Invalid Statement/
Stack:
#0 0x00007ffff703f625 in raise () from /lib64/libc.so.6
#1 0x00007ffff7040d8d in abort () from /lib64/libc.so.6
#2 0x00007ffff6222c55 in os::abort(bool) ()
from /usr/java/
#3 0x00007ffff63a4cd7 in VMError:
from /usr/java/
#4 0x00007ffff6227b6f in JVM_handle_
from /usr/java/
#5 <signal handler called>
#6 ExpDatetime:
srcData=
dstLen=11, heap=0x7fff9d58
at ../exp/
#7 0x00007ffface10ba2 in convAsciiToDatetime (target=
targetLen=11, code=REC_
fractionPre
sourceLen=
flags=0) at ../exp/
#8 0x00007ffface147b1 in convDoIt (source=0x7b4800 "\027",
sourceLen=
target=
targetScale=6, varCharLen=0x0, varCharLenSize=0, heap=0x7fff9d58
diagsArea=
---Type <return> to continue, or q <return> to quit---
dataConvers
#9 0x00007fffae36e935 in InputOutputExpr
atp=<optimized out>, inputDesc_
heap=
at ../cli/
#10 0x00007fffaea05881 in ex_root_
0x7fff9d5a8ed8, input_desc=
@0x7ffff7fd
#11 0x00007fffae3aec65 in CliStatement:
cliGlobals=
diagsArea=..., doNormalExecute
reExecute=
#12 0x00007fffae35baeb in SQLCLI_
statement_
num_
input_
#13 0x00007fffae3c1599 in SQL_EXEC_
input_
num_
#14 0x00007fffb0471cdc in EXECUTE (pSrvrStmt=
at native/
---Type <return> to continue, or q <return> to quit---
#15 0x00007fffb046cf2e in SRVR_STMT_
inCursorNam
inValueList
inQueryTime
#16 0x00007fffb04828bc in odbc_SQLSvc_
call_
dialogueId=
sqlStmtType=0, totalRowCount=1, inputValueList=
sqlAsyncEna
sqlWarning=
#17 0x00007fffb047b7ac in Java_org_
dialogueId=
stmtId=
paramCount=9, paramValues=
isAnyLob=0 '\000', iso88591Encodin
contBatchOn
#18 0x00007ffff21b37f8 in ?? ()
#19 0x0000000000000002 in ?? ()
#20 0x0000000000e98160 in ?? ()
#21 0x0000000000000000 in ?? ()
(gdb)
Changed in trafodion: | |
assignee: | nobody → Pavani Puppala (pavani-puppala) |
Changed in trafodion: | |
assignee: | Pavani Puppala (pavani-puppala) → nobody |
tags: | added: connectivity-mxosrvr |
Changed in trafodion: | |
assignee: | nobody → Kevin Xu (kai-hua-xu) |
The problem is because the source length is too big. This pointed back to where we get the source length. For varchars the length is stored either in first two or first four bytes. That is checked by reading var indicator length to decide if the length is in the first two or four bytes. However T2 and T4 are not setting var indicator length for varchar types in input descriptors in T2 and T4. This need to be fixed.