[
https://issues.apache.org/jira/browse/TRAFODION-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706303#comment-14706303
]
Atanu Mishra commented on TRAFODION-227:
----------------------------------------
QF Chen (qifan-chen) wrote on 2014-04-21: #1
The problem is with the handling of encoded keys for varchar columns. The
length of the encoded key is not taken from varchar length field embedded in
the decoded result buffer. As a result, a value of over 6000 bytes is
considered the length of the decoded key. When these bytes are accessed,
illegal memory access occurs.
The fix is applied to getRangePartitionBoundaryValuesFromEncodedKeys(),
NATable.cpp.
Changed in trafodion:
status: In Progress → Fix Committed
QF Chen (qifan-chen) on 2014-04-23
Changed in trafodion:
milestone: none → r0.6
Weishiun Tsai (wei-shiun-tsai) wrote on 2014-05-09: #2
Verified on the datalake build v40183 installed on the cluster rhel-cdh1. This
set of queries no longer generate cores. The problem has been fixed.
Changed in trafodion:
status: Fix Committed → Fix Released
> LP Bug: 1308306 - Tdm_arkcmp cores when running Opencart queries
> ----------------------------------------------------------------
>
> Key: TRAFODION-227
> URL: https://issues.apache.org/jira/browse/TRAFODION-227
> Project: Apache Trafodion
> Issue Type: Bug
> Components: sql-cmp
> Reporter: Weishiun Tsai
> Assignee: Qifan Chen
> Priority: Critical
> Fix For: 0.6 (pre-incubation), 0.8 (pre-incubation)
>
>
> With the set of Opencart queries that Venkat ported over for Trafodion, they
> generated lots of tdm_arkcmp cores. Opencart DDLs and DMLs have been ported
> as part of the QA regression test. The select queries that caused the cores
> did not return error messages, but running the entire set of Opencart queries
> left about 166 of cores on the node. The core files can be found at the
> $SQ_HOME directory of the node where mxosrvr runs. After the test is
> started, one can check the DCS master-status page when the DMLs are running
> to find out the connection node where the cores could be found.
> This is seen on the beta v39140 build installed on the cluster centos-mapr1.
> A typical stack trace of such core looks like the following.
> (gdb) bt
> #0 0x0000003db38328e5 in raise () from /lib64/libc.so.6
> #1 0x0000003db38340c5 in abort () from /lib64/libc.so.6
> #2 0x00007f0446b0a8b5 in ?? ()
> from /usr/lib/jvm/java/jre/lib/amd64/server/libjvm.so
> #3 0x00007f0446c7878f in ?? ()
> from /usr/lib/jvm/java/jre/lib/amd64/server/libjvm.so
> #4 0x00007f0446b0fa82 in JVM_handle_linux_signal ()
> from /usr/lib/jvm/java/jre/lib/amd64/server/libjvm.so
> #5 <signal handler called>
> #6 0x00007f044a417954 in
> RangePartitionBoundaries::getOptimizedNumberOfPartKeys (this=<value optimized
> out>) at ../optimizer/PartFunc.cpp:3158
> #7 0x00007f044a4293eb in
> RangePartitioningFunction::createPartitioningFunctionForIndexDesc
> (this=0x7f042ae87ec0, idesc=0x7f042ae3d4e0)
> at ../optimizer/PartFunc.cpp:4152
> #8 0x00007f044a1b8e48 in IndexDesc::IndexDesc (this=0x7f042ae3d4e0,
> tdesc=0x7f042ae36f50, fileSet=0x7f042ae88138, cmpContext=0x7f042ae88138)
> at ../optimizer/IndexDesc.cpp:225
> #9 0x00007f044a09070e in createTableDesc2 (bindWA=<value optimized out>,
> naTable=0x7f042ae7f0f8, corrName=..., hint=0x0)
> at ../optimizer/BindRelExpr.cpp:1568
> #10 0x00007f044a091e7f in BindWA::createTableDesc (this=0x7fffd8cc4f80,
> naTable=0x7f042ae7f0f8, corrName=..., catmanCollectUsages=0,
> hint=<value optimized out>) at ../optimizer/BindRelExpr.cpp:1646
> #11 0x00007f044a0a5f87 in Scan::bindNode (this=0x7f042bcc2fa8,
> bindWA=0x7fffd8cc4f80) at ../optimizer/BindRelExpr.cpp:6723
> #12 0x00007f044a07ce57 in RelExpr::bindChildren (this=0x7f042bcc3a20,
> bindWA=0x7fffd8cc4f80) at ../optimizer/BindRelExpr.cpp:2164
> #13 0x00007f044a0b9ea1 in Join::bindNode (this=0x7f042bcc3a20,
> bindWA=0x7fffd8cc4f80) at ../optimizer/BindRelExpr.cpp:2498
> #14 0x00007f044a07ce57 in RelExpr::bindChildren (this=0x7f042bccf1a8,
> bindWA=0x7fffd8cc4f80) at ../optimizer/BindRelExpr.cpp:2164
> #15 0x00007f044a0b9ea1 in Join::bindNode (this=0x7f042bccf1a8,
> bindWA=0x7fffd8cc4f80) at ../optimizer/BindRelExpr.cpp:2498
> #16 0x00007f044a07ce57 in RelExpr::bindChildren (this=0x7f042bcd3bf0,
> bindWA=0x7fffd8cc4f80) at ../optimizer/BindRelExpr.cpp:2164
> #17 0x00007f044a0b7296 in RelRoot::bindNode (this=0x7f042bcd3bf0,
> bindWA=0x7fffd8cc4f80) at ../optimizer/BindRelExpr.cpp:5001
> #18 0x00007f044ce6b524 in CmpMain::compile (this=0x7fffd8cc71b0,
> input_str=0x7f042bcc7c28 "SELECT COUNT(DISTINCT p.product_id) AS total
> FROM oc_category_path cp LEFT JOIN oc_product_to_category p2c ON
> (cp.category_id = p2c.category_id) LEFT JOIN oc_product p ON (p2c.product_id
> = p.product_i"...,
> charset=15, queryExpr=@0x7fffd8cc70e8, gen_code=0x7f042ae96b88,
> gen_code_len=0x7f042ae96b80, heap=0x7f043e40adb8, phase=CmpMain::END,
> fragmentDir=0x7fffd8cc7308, op=3004, useQueryCache=<value optimized out>,
> cacheable=0x7fffd8cc70f8, begTime=0x7fffd8cc70d0, shouldLog=0)
> at ../sqlcomp/CmpMain.cpp:1755
> #19 0x00007f044ce6de5e in CmpMain::sqlcomp (this=0x7fffd8cc71b0,
> input_str=0x7f042bcc7c28 "SELECT COUNT(DISTINCT p.product_id) AS total
> FROM oc_category_path cp LEFT JOIN oc_product_to_category p2c ON
> (cp.category_id = p2c.category_id) LEFT JOIN oc_product p ON (p2c.product_id
> = p.product_i"...,
> charset=15, queryExpr=@0x7fffd8cc70e8, gen_code=0x7f042ae96b88,
> gen_code_len=0x7f042ae96b80, heap=0x7f043e40adb8, phase=CmpMain::END,
> fragmentDir=0x7fffd8cc7308, op=3004, useQueryCache=1,
> cacheable=0x7fffd8cc70f8, begTime=0x7fffd8cc70d0, shouldLog=0)
> at ../sqlcomp/CmpMain.cpp:1425
> #20 0x00007f044ce6f039 in CmpMain::sqlcomp (this=0x7fffd8cc71b0, input=...,
> gen_code=0x7f042ae96b88, gen_code_len=0x7f042ae96b80, heap=0x7f043e40adb8,
> phase=CmpMain::END, fragmentDir=0x7fffd8cc7308, op=3004)
> at ../sqlcomp/CmpMain.cpp:762
> #21 0x00007f044976849f in CmpStatement::process (this=0x7f042bce6ef8,
> sqltext=<value optimized out>) at ../arkcmp/CmpStatement.cpp:474
> #22 0x00007f044975a825 in ExCmpMessage::actOnReceive (this=0x7fffd8cc8040)
> at ../arkcmp/CmpConnection.cpp:348
> #23 0x00007f044c564f96 in IpcMessageStream::internalActOnReceive (
> this=0x7fffd8cc8040, buffer=<value optimized out>, connection=0x25f4030)
> at ../common/Ipc.cpp:3541
> #24 0x00007f044c57bfeb in GuaConnectionToClient::acceptBuffer (this=0x25f4030,
> buffer=<value optimized out>, receivedDataLength=<value optimized out>)
> at ../common/IpcGuardian.cpp:2455
> #25 0x00007f044c57ccef in GuaReceiveControlConnection::wait (this=0x25e3860,
> timeout=-1, eventConsumed=<value optimized out>,
> ipcAwaitiox=0x7fffd8cc79f0) at ../common/IpcGuardian.cpp:3152
> #26 0x00007f044c57e0d2 in GuaConnectionToClient::wait (this=0x25f4030,
> timeout=<value optimized out>, eventConsumed=0x0, ipcAwaitiox=0x0)
> at ../common/IpcGuardian.cpp:2124
> #27 0x00007f044c5716ea in IpcSetOfConnections::waitOnSet (this=0x7fffd8cc81e0,
> timeout=-1, calledByESP=0, timedout=0x0) at ../common/Ipc.cpp:1697
> #28 0x00007f044c57222d in IpcMessageStream::waitOnMsgStream (
> this=0x7fffd8cc8040, timeout=-1) at ../common/Ipc.cpp:3260
> #29 0x00007f044c572572 in IpcMessageStream::receive (this=0x7fffd8cc8040,
> waited=1) at ../common/Ipc.cpp:3242
> #30 0x0000000000405c1a in main (argc=2, argv=0x7fffd8cc87b8)
> at ../bin/arkcmp.cpp:341
> (gdb)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
