[ 
https://issues.apache.org/jira/browse/TRAFODION-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14696255#comment-14696255
 ] 

Atanu Mishra commented on TRAFODION-177:
----------------------------------------

Hans Zeller (hans-zeller) wrote on 2014-02-20:  #3
Download full text (4.1 KiB)
This might have to do with the fact that salted tables are pre-split into 
multiple regions. I checked the query plan and it seems to handle the salting 
column correctly. Could someone from the TM team have a look?

The call stack looks like this:

Core was generated by `sqlci'.
Program terminated with signal 6, Aborted.
#0 0x00000033de4328a5 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x00000033de4328a5 in raise () from /lib64/libc.so.6
#1 0x00000033de434085 in abort () from /lib64/libc.so.6
#2 0x00007ffff6c93455 in os::abort(bool) () from 
/opt/home/tools/jdk1.7.0_09_64/jre/lib/amd64/server/libjvm.so
#3 0x00007ffff6df3717 in VMError::report_and_die() ()
   from /opt/home/tools/jdk1.7.0_09_64/jre/lib/amd64/server/libjvm.so
#4 0x00007ffff6df3cee in crash_handler(int, siginfo*, void*) ()
   from /opt/home/tools/jdk1.7.0_09_64/jre/lib/amd64/server/libjvm.so
#5 <signal handler called>
#6 0x00007ffff6c4a635 in methodOopDesc::name_and_sig_as_C_string(char*, int) 
const ()
   from /opt/home/tools/jdk1.7.0_09_64/jre/lib/amd64/server/libjvm.so
#7 0x00007ffff69d1714 in frame::print_on_error(outputStream*, char*, int, bool) 
const ()
   from /opt/home/tools/jdk1.7.0_09_64/jre/lib/amd64/server/libjvm.so
#8 0x00007ffff6df17f0 in VMError::print_stack_trace(outputStream*, JavaThread*, 
char*, int, bool) ()
   from /opt/home/tools/jdk1.7.0_09_64/jre/lib/amd64/server/libjvm.so
#9 0x00007ffff6df1f95 in VMError::report(outputStream*) ()
   from /opt/home/tools/jdk1.7.0_09_64/jre/lib/amd64/server/libjvm.so
#10 0x00007ffff6df331a in VMError::report_and_die() ()
   from /opt/home/tools/jdk1.7.0_09_64/jre/lib/amd64/server/libjvm.so
#11 0x00007ffff6c96f60 in JVM_handle_linux_signal ()
   from /opt/home/tools/jdk1.7.0_09_64/jre/lib/amd64/server/libjvm.so
#12 <signal handler called>
#13 0x00000033de48997b in memcpy () from /lib64/libc.so.6
#14 0x00007ffff0f9fc9f in 
Java_org_apache_hadoop_hbase_client_transactional_RMInterface_registerRegion (
    pp_env=0x32be1d8, pv_object=0x7fffffff34d8, pv_string=0x7fffffff34d0, 
pv_dos=0x7fffffff34c8)
    at tmregisterregion.cpp:30
#15 0x785c3030785c3030 in ?? ()
#16 0x785c3030785c3030 in ?? ()
#17 0x785c3030785c3030 in ?? ()
#18 0x785c3030785c3030 in ?? ()
#19 0x785c3030785c3030 in ?? ()
#20 0x785c3030785c3030 in ?? ()
#21 0x785c3030785c3030 in ?? ()
#22 0x785c3030785c3030 in ?? ()
#23 0x785c3030785c3030 in ?? ()
#24 0x785c3030785c3030 in ?? ()
#25 0x785c3030785c3030 in ?? ()
#26 0x785c3030785c3030 in ?? ()
#27 0x785c3030785c3030 in ?? ()
#28 0x785c3030785c3030 in ?? ()
#29 0x785c3030785c3030 in ?? ()
#30 0x434e45202c273030 in ?? ()
#31 0x203e3d204445444f in ?? ()
#32 0x3162393231346231 in ?? ()
#33 0x6439633639643466 in ?? ()
#34 0x6663633730363634 in ?? ()
#35 0x6638653439626264 in ?? ()
#36 0x4e54534f48207d2c in ?? ()
#37 0x7434677c3a454d41 in ?? ()
#38 0x756f682e33343033 in ?? ()
#39 0x2e70682e6e6f7473 in ?? ()
#40 0x54524f507c6d6f63 in ?? ()
#41 0x38343735357c203a in ?? ()
#42 0x00007fffffff357c in ?? ()
#43 0x00007fffc8d14333 in ?? ()
#44 0x000000060d71ef10 in ?? ()
#45 0x000000060d71e918 in ?? ()
#46 0x000000060d71e8d0 in ?? ()
#47 0x000000060d71de80 in ?? ()
#48 0x000000060d6dd560 in ?? ()
#49 0x000000060d6dc470 ...

Read more...

Changed in trafodion:
status: New → Confirmed
summary:        - INSERT into salted table via SQLCI causes SQLCI core.
+ INSERT into salted (multi-region) table via SQLCI causes SQLCI core.
Hans Zeller (hans-zeller) wrote on 2014-02-20:  #4
Two more observations:

If I suppress pre-splitting the salted table (set numSplits in 
CmpSeabaseDDL::createSeabaseTable() in file sql/sqlcomp/CmpSeaBaseDDLtable.cpp 
to 0), then the statement succeeds.

If I run this in auto-commit mode (no begin work) it succeeds as well.

Oliver Bucaojit (oliver-bucaojit) on 2014-02-21
Changed in trafodion:
assignee:       nobody → Oliver (oliver-bucaojit)
Oliver Bucaojit (oliver-bucaojit) wrote on 2014-02-21:  #5
Download full text (19.4 KiB)
I have a fix for this issue, it is being caused by salted tables having a 
longer regionInfo length than unsalted tables due to the startkey and endkey 
being present in the region name as opposed to them being blank, which is what 
we encountered in the past.

The core was being caused by a memcpy() copying values into a buffer that 
wasn't large enough.

My fix is a simple increase of MAX expected size of the region name from 1024 
to 2048.

--- log of sqlci test ---
sqlci
Hewlett-Packard NonStop(TM) SQL/MX Conversational Interface 2.5
(c) Copyright 2003-2010 Hewlett-Packard Development Company, LP.
>>SET SCHEMA TRAFODION.TESTSCH;

--- SQL operation complete.
>>SET WARNINGS OFF;
>>-- Insert CPU Rows
>>Prepare CMD from
+>INSERT INTO CPU (SYSTEMNAME, LOADID, INITDATETIME, LOADDATETIME, NODEID, 
SAMPLEDATETIME,
+>
+>COLLECTMODE, CPUNUM, USERBUSY, NICEBUSY, SYSTEMBUSY, IDLETIME, TOTTIME, 
WAITTIME, IRQTIME,
+>
+>SOFTIRQTIME, STEALTIME) VALUES
+>
+>('ZIRCON2','SB1401301516','20140130151707','20140130220941','n001',?, 'D', ?, 
?, ?, ?, ?, ?, ?,
+>
+>?, ?, ?);
BEGIN WORK;
SHOW SESSION;
EXECUTE CMD USING
'20140130151800', 0, 0.24500, 0.00600, 0.19000, 0.46800, 0.49900, 0.00000, 
0.00000, 0.05800,

0.00000;

--- SQL command prepared.
>>
--- SQL operation complete.
>>----------------------------------
Current Environment
----------------------------------
CURRENT DIRECTORY 
/opt/home/bucaojit/eeseatrans/sqf/src/seatrans/hbase-trx/src/main/java/org/apache/h
 adoop/hbase/client/transactional
LIST_COUNT 4294967295
LOG FILE
MESSAGEFILE /opt/home/bucaojit/eeseatrans/sqf/export/bin64d/mxcierr ...
TERMINAL CHARSET ISO88591
MESSAGEFILE LANG US English
MESSAGEFILE VRSN {2014-01-30 17:52 LINUX:G4T3036.HOUSTON.HP.COM/bucaojit}
SQL USER NAME DB__ROOT
SQL USER ID 99999
SQL CATALOG TRAFODION
SQL SCHEMA TESTSCH
TRANSACTION ID 46001
TRANSACTION STATE in progress
WARNINGS off
>>+>+>+>
--- 1 row(s) inserted.
>>EXECUTE CMD USING
+>'20140130151800', 1, 0.22900, 0.00500, 0.09500, 0.62800, 0.33300, 0.00000, 
0.00000, 0.00400, 0.00000 ;

--- 1 row(s) inserted.
>>EXECUTE CMD USING
+>'20140130151800', 2, 0.11400, 0.01300, 0.09100, 0.75300, 0.22800, 0.00000, 
0.00000, 0.01000, 0.00000 ;
EXECUTE CMD USING

--- 1 row(s) inserted.
>>+>'20140130151800', 3, 0.06900, 0.00900, 0.04800, 0.86000, 0.13100, 0.00000, 
>>0.00000, 0.00500, 0.000 00;

--- 1 row(s) inserted.
>>EXECUTE CMD USING
+>'20140130151800', 4, 0.01400, 0.00700, 0.04400, 0.92000, 0.06800, 0.00000, 
0.00000, 0.00300, 0.00000 ;
EXECUTE CMD USING
'20140130151800', 5, 0.01000, 0.00700, 0.05500, 0.92700, 0.07300, 0.00000, 
0.00000, 0.00100, 0.0...

Oliver Bucaojit (oliver-bucaojit) wrote on 2014-03-12:  #6
Fix has been checked-in to trafodion_beta, seatrans_2, and datalake. The change 
has been verified by Guy.

Changed in trafodion:
status: Confirmed → Fix Committed
Weishiun Tsai (wei-shiun-tsai) on 2014-04-09
tags:   added: sql-general
removed: salting
Weishiun Tsai (wei-shiun-tsai) on 2014-04-10
tags:   added: sql-exe
removed: sql-general
Guy Groulx (guy-groulx) wrote on 2014-05-12:    #7
Tested with datalake v40224 and it works now.

Changed in trafodion:
status: Fix Committed → Fix Released


> LP Bug: 1274750 - INSERT into salted (multi-region) table via SQLCI causes 
> SQLCI core.
> --------------------------------------------------------------------------------------
>
>                 Key: TRAFODION-177
>                 URL: https://issues.apache.org/jira/browse/TRAFODION-177
>             Project: Apache Trafodion
>          Issue Type: Bug
>          Components: sql-exe
>            Reporter: Guy Groulx
>            Assignee: Oliver Bucaojit
>            Priority: Critical
>             Fix For: 1.0 (pre-incubation)
>
>
> Prepare CMD from 
> +>INSERT INTO CPU (SYSTEMNAME, LOADID, INITDATETIME, LOADDATETIME, NODEID, 
> SAMPLEDATETIME, COLLECTMODE, CPUNUM, USERBUSY, NICEBUSY, SYSTEMBUSY, 
> IDLETIME, TOTTIME, WAITTIME, IRQTIME, SOFTIRQTIME, STEALTIME) VALUES 
> ('ZIRCON2','SB1401301516','20140130151707','20140130220941','n001',?, 'D', ?, 
> ?, ?, ?, ?, ?, ?, ?, ?, ?);
> --- SQL command prepared.
> >>BEGIN WORK;
> --- SQL operation complete.
> >>EXECUTE CMD USING 
> +>'20140130151800', 0, 0.24500, 0.00600, 0.19000, 0.46800, 0.49900, 0.00000, 
> 0.00000, 0.05800, 0.00000;
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x00007ffff6949a48, pid=36759, tid=140737353866944
> #
> # JRE version: 7.0_09-b05
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (23.5-b02 mixed mode linux-amd64 
> compressed oops)
> # Problematic frame:
> # V  [libjvm.so+0x566a48]  jni_ReleaseByteArrayElements+0x98
> #
> # Core dump written. Default location: /home/squser2/guy/core or core.36759
> #
> # An error report file with more information is saved as:
> # /home/squser2/guy/hs_err_pid36759.log
> #
> # If you would like to submit a bug report, please visit:
> #   http://bugreport.sun.com/bugreport/crash.jsp
> #
> Aborted (core dumped)
> I've attached input file to feed SQLCI to try out.
> The generated log file is available on ZIRCON at the location above.
> Core file is on ZIRCON on n001
> 2014-01-30 22:53:43 /local/cores/1003/core.1391122421.n001.36759.sqlci
> Core was generated by `sqlci'.
> Program terminated with signal 6, Aborted.
> #0  0x00007ffff585c8a5 in raise () from /lib64/libc.so.6
> #1  0x00007ffff585e085 in abort () from /lib64/libc.so.6
> #2  0x00007ffff6b28455 in os::abort(bool) () from 
> /home/tools/jdk1.7.0_09_64/jre/lib/amd64/server/libjvm.so
> #3  0x00007ffff6c88717 in VMError::report_and_die() () from 
> /home/tools/jdk1.7.0_09_64/jre/lib/amd64/server/libjvm.so
> #4  0x00007ffff6c88cee in crash_handler(int, siginfo*, void*) () from 
> /home/tools/jdk1.7.0_09_64/jre/lib/amd64/server/libjvm.so
> #5  <signal handler called>
> #6  0x00007ffff6adf635 in methodOopDesc::name_and_sig_as_C_string(char*, int) 
> const ()
>    from /home/tools/jdk1.7.0_09_64/jre/lib/amd64/server/libjvm.so
> #7  0x00007ffff6866714 in frame::print_on_error(outputStream*, char*, int, 
> bool) const ()
>    from /home/tools/jdk1.7.0_09_64/jre/lib/amd64/server/libjvm.so
> #8  0x00007ffff6c867f0 in VMError::print_stack_trace(outputStream*, 
> JavaThread*, char*, int, bool) ()
>    from /home/tools/jdk1.7.0_09_64/jre/lib/amd64/server/libjvm.so
> #9  0x00007ffff6c86f95 in VMError::report(outputStream*) () from 
> /home/tools/jdk1.7.0_09_64/jre/lib/amd64/server/libjvm.so
> #10 0x00007ffff6c8831a in VMError::report_and_die() () from 
> /home/tools/jdk1.7.0_09_64/jre/lib/amd64/server/libjvm.so
> #11 0x00007ffff6b2bf60 in JVM_handle_linux_signal () from 
> /home/tools/jdk1.7.0_09_64/jre/lib/amd64/server/libjvm.so
> #12 <signal handler called>
> #13 0x00007ffff6949a48 in jni_ReleaseByteArrayElements () from 
> /home/tools/jdk1.7.0_09_64/jre/lib/amd64/server/libjvm.so
> #14 0x00007ffff1894aa1 in ReleaseByteArrayElements (pp_env=0xbec9d8, 
> pv_object=<value optimized out>, 
>     pv_string=<value optimized out>, pv_dos=0x7fffffff4f38) at 
> /opt/home/tools/jdk1.7.0_09_64/include/jni.h:1697
> #15 
> Java_org_apache_hadoop_hbase_client_transactional_RMInterface_registerRegion 
> (pp_env=0xbec9d8, pv_object=<value optimized out>, 
>     pv_string=<value optimized out>, pv_dos=0x7fffffff4f38) at 
> tmregisterregion.cpp:35
> #16 0x785c3030785c3030 in ?? ()
> ...
> #30 0x785c3030785c3030 in ?? ()
> #31 0x434e45202c273030 in ?? ()
> #32 0x203e3d204445444f in ?? ()
> #33 0x3966373836643866 in ?? ()
> #34 0x3035383864323564 in ?? ()
> #35 0x3464613834653162 in ?? ()
> #36 0x3531383263626662 in ?? ()
> #37 0x4e54534f48207d2c in ?? ()
> #38 0x31306e7c3a454d41 in ?? ()
> #39 0x756c632e6d632e30 in ?? ()
> #40 0x524f507c72657473 in ?? ()
> #41 0x323030367c203a54 in ?? ()
> ---Type <return> to continue, or q <return> to quit---
> #42 0x00007fffffff7c30 in ?? ()
> #43 0x00007fffffff5048 in ?? ()
> #44 0x00007fffe21c9333 in ?? ()
> #45 0x000000059cc39da8 in ?? ()
> #46 0x000000059cc397b0 in ?? ()
> #47 0x000000059cc39768 in ?? ()
> #48 0x000000059cc38d28 in ?? ()
> #49 0x000000059cbf8868 in ?? ()
> #50 0x000000059cbf7790 in ?? ()
> #51 0x000000059ca836a0 in ?? ()
> #52 0x0000000000000000 in ?? ()
> (gdb) 
> NOTE:   If the SALT clause is not specified in the CREATE TABLE, it all works.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to