[TRAFODION-2854] Load encounter Operating system error 201

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 2.3
• Component/s: sql-exe
• Assignee: Selvaganesan Govindarajan
• Reporter: Selvaganesan Govindarajan
• Created: 18/Dec/17 23:30
• Updated: 15/Sep/18 07:32
• Resolved: 03/Jan/18 19:40

Description

Load data from hive data encounter 201 error, but using uspert using load the error is different

>>load with log error rows to '/bulkload/logs' into TRAFODION.ODS_SC.DM_FUNCTION_LOCATION select * from hive.hive.DM_FUNCTION_LOCATION;
Task: LOAD Status: Started Object: TRAFODION.ODS_SC.DM_FUNCTION_LOCATION
Task: CLEANUP Status: Started Time: 2017-12-15 10:04:17.366
Task: CLEANUP Status: Ended Time: 2017-12-15 10:04:17.385
Task: CLEANUP Status: Ended Elapsed Time: 00:00:00.019
Logging Location: /bulkload/logs/ERR_TRAFODION.ODS_SC.DM_FUNCTION_LOCATION_20171215_020417
Task: LOADING DATA Status: Started Time: 2017-12-15 10:04:17.385

• • • ERROR[2034] $Z000RN4:502: Operating system error 201 while communicating with server process $Z0211QE:526.

• • • ERROR[2034] $Z000RN4:502: Operating system error 201 while communicating with server process $Z0211QE:526.

• • • ERROR[2034] $Z000RN4:502: Operating system error 201 while communicating with server process $Z0211QE:526.

SQL>upsert using load into TRAFODION.ODS_SC.DM_FUNCTION_LOCATION select * from hive.hive.DM_FUNCTION_LOCATION;

• • • ERROR[8411] A numeric overflow occurred during an arithmetic computation or data conversion. Conversion of Source Type:CHAR(REC_BYTE_F_ASCII,15 BYTES,ISO88591) Source Value:214040391595900 to Target Type:DECIMAL SIGNED(REC_DECIMAL_LSE). [2017-12-15 13:46:59]
      Additional Information Core file and stack trace are under 10.10.22.152:/opt/GuangXi_20171218

Account: root/linux

Step to analyze core:
[root@esggy-del-n002 GuangXi_20171218]# gdb
(gdb) source zgdb-GuangXi_20171218-
(gdb) file /opt/esgynDB223/export/bin64/tdm_arkesp
(gdb) core core.44989
(gdb) bt
#0 0x00007f440e0ea1d7 in raise () from /opt/GuangXi_20171218/lib64/libc.so.6
#1 0x00007f440e0eb8c8 in abort () from /opt/GuangXi_20171218/lib64/libc.so.6
#2 0x00007f4410039f85 in os::abort(bool) () from /opt/GuangXi_20171218/opt/jdk1.8.0_112/jre/lib/amd64/server/libjvm.so
#3 0x00007f44101dc383 in VMError::report_and_die() () from /opt/GuangXi_20171218/opt/jdk1.8.0_112/jre/lib/amd64/server/libjvm.so
0000004 0x00007f441003f48f in JVM_handle_linux_signal () from /opt/GuangXi_20171218/opt/jdk1.8.0_112/jre/lib/amd64/server/libjvm.so
0000005 0x00007f44100359d3 in signalHandler(int, siginfo*, void*) ()
from /opt/GuangXi_20171218/opt/jdk1.8.0_112/jre/lib/amd64/server/libjvm.so
0000006 <signal handler called>
0000007 0x00007f440e1ffde0 in __memcpy_ssse3_back () from /opt/GuangXi_20171218/lib64/libc.so.6
0000008 0x00007f441308aeaf in str_cpy_all (length=-7167, src=<error reading variable: Cannot access memory at address 0xbc>,
tgt=0x7fff64f1ed60 "\200") at ../common/str.h:265
0000009 getLength (data=<error reading variable: Cannot access memory at address 0xbc>, this=0x80) at ../exp/exp_attrs.h:415
0000010 ExHbaseAccessBulkLoadPrepSQTcb::createLoggingRow (this=<optimized out>, tuppIndex=<optimized out>, tuppRow=0x7f43fe67e3d0 "",
targetRow=0x7f43fe68e401 "", targetRowLen=@0x7fff64f1eea0: 0) at ../executor/ExHbaseIUD.cpp:1754
0000011 0x00007f441308ed1c in ExHbaseAccessBulkLoadPrepSQTcb::work (this=0x7f43fe662f48) at ../executor/ExHbaseIUD.cpp:1591
0000012 0x00007f441309b46f in donotUpdateCounters (this=0x1343d9928) at ../executor/ExStats.h:3729
0000013 ExScheduler::work (this=0x7f44141a2008, prevWaitTime=<optimized out>) at ../executor/ExScheduler.cpp:296
0000014 0x00007f4412fc69ed in ExEspFragInstanceDir::fixupEntry (this=0x0, handle=320060680, numOfParentInstances=1693577552, da=...)
at ../executor/ex_esp_frag_dir.cpp:331
0000015 0x000000000040ca26 in runESP (argc=argc@entry=3, argv=argv@entry=0x7fff64f1f878, guaReceiveFastStart=guaReceiveFastStart@entry=0x0)
at ../bin/ex_esp_main.cpp:404
0000016 0x000000000040bd9b in main (argc=3, argv=0x7fff64f1f878) at ../bin/ex_esp_main.cpp:258
(gdb)

This issue was observed at a customer installation that deployed EsgynDB

Issue Links

• links to: GitHub Pull Request #1364