[MCOL-631] Create table caused primproc crashed for a specific configuration Created: 2017-03-21  Updated: 2019-07-10  Resolved: 2019-07-10

Status: Closed
Project: MariaDB ColumnStore
Component/s: PrimProc
Affects Version/s: 1.0.7, 1.0.8
Fix Version/s: Icebox

Type: Bug Priority: Major
Reporter: Daniel Lee (Inactive) Assignee: David Hall (Inactive)
Resolution: Duplicate Votes: 1
Labels: relnote

Sprint: 2017-10, 2017-11, 2017-12, 2017-13

 Description   

Build tested: 1.0.7-1, 1.0.8-1

The issue occurs on the following specific setup

ubuntu16.04 (did not check on 14.04)
1um 2pm
local query enabled
non root installation

Mr. Hill also reproduced the issue in his environment:

MariaDB [david]> create table tmp (c1 int) engine=columnstore;
ERROR 1815 (HY000): Internal error: CAL0009: IDB-2031: Blocks are missing. Alter or drop table in progress?
MariaDB [david]>

I used Mr. Hill's terminal output above since I forgot to capture it in my test.

Mar 21 16:45:20 vagrant controllernode[5252]: 20.941541 |0|0|0| C 29 CAL0000: BRMShmImpl::BRMShmImpl(): retrying on size==0
Mar 21 16:45:20 vagrant joblist[7319]: 20.958232 |0|0|0| C 05 CAL0000: /home/builder/mariadb-columnstore-server/mariadb-columnstore-engine/dbcon/joblist/distributedenginecomm.cpp @ 382 DEC: lost connection to 10.0.0.21
Mar 21 16:45:21 vagrant ProcessMonitor[4002]: 21.228480 |0|0|0| C 18 CAL0000: *****Calpont Process Restarting: PrimProc, old PID = 5252

When I tried to create a table, I got the following in crit.log

Mar 21 16:56:40 vagrant PrimProc[27821]: 40.209536 |0|0|0| C 28 CAL0000: IDB-2031: Blocks are missing. Alter or drop table in progress?
Mar 21 16:56:40 vagrant PrimProc[27821]: 40.209769 |0|0|0| C 28 CAL0000: IDB-2031: Blocks are missing. Alter or drop table in progress?

after restarting the stack, create table worked.

The same test for root user worked fine

 Comments   
Comment by David Hill (Inactive) [ 2017-03-22 ]

Thread 15 "PrimProc" received signal SIGABRT, Aborted.
[Switching to Thread 0x7f1a3eff5700 (LWP 7499)]
0x00007f1a4c79d428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
54 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 0x00007f1a4c79d428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1 0x00007f1a4c79f02a in __GI_abort () at abort.c:89
#2 0x00007f1a4d0df84d in _gnu_cxx::_verbose_terminate_handler() ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x00007f1a4d0dd6b6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4 0x00007f1a4d0dd701 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5 0x00007f1a4d0dd716 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00007f1a4d0dd342 in __cxa_call_unexpected () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#7 0x00007f1a4ff4cffd in BRM::DBRM::vssLookup(long, BRM::QueryContext const&, int, int*, bool*, bool) ()
from /home/guest/mariadb/columnstore/lib/libbrm.so.1
#8 0x0000000000496743 in primitiveprocessor::loadBlock(unsigned long, BRM::QueryContext, unsigned int, int, void*, bool*, unsigned int*, bool, unsigned int, bool, std::tr1::unordered_map<long, BRM::VSSData, std::tr1::hash<long>, std::equal_to<long>, std::allocator<std::pair<long const, BRM::VSSData> > >*) [clone .constprop.588] ()
#9 0x000000000049a140 in (anonymous namespace)::DictScanJob::operator()() ()
#10 0x00007f1a4d6118a9 in threadpool::PriorityThreadPool::threadFcn(threadpool::PriorityThreadPool::Priority) ()
from /home/guest/mariadb/columnstore/lib/libthreadpool.so.1
#11 0x00007f1a4e9305d5 in ?? () from /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.58.0
#12 0x00007f1a4dde66ba in start_thread (arg=0x7f1a3eff5700) at pthread_create.c:333
#13 0x00007f1a4c86e82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
(gdb)

Comment by David Hill (Inactive) [ 2017-03-22 ]

problem was found to be that the dbrm data wasnt loaded into shared memory, which is causing the primproc crash... only happens when the local query flag is set at install on a new system.

System Catalog Successfully Created

Run MariaDB ColumnStore Replication Setup.. DONE

MariaDB ColumnStore Install Successfully Completed, System is Active

Enter the following command to define MariaDB ColumnStore Alias Commands

. /home/guest/mariadb/columnstore/bin/columnstoreAlias

Enter 'mcsmysql' to access the MariaDB ColumnStore SQL console
Enter 'mcsadmin' to access the MariaDB ColumnStore Admin console

guest@ubuntu16-pm1:~$ home
guest@ubuntu16-pm1:~/mariadb/columnstore$ home
guest@ubuntu16-pm1:~/mariadb/columnstore$ cd bin
guest@ubuntu16-pm1:~/mariadb/columnstore/bin$
guest@ubuntu16-pm1:~/mariadb/columnstore/bin$ ./editem -i

Comment by David Hill (Inactive) [ 2017-03-22 ]

work-around...

after the postConfigure successfully completes, do the following

  1. ma restartsystem y
Generated at Thu Feb 08 02:22:32 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.