[MCOL-4283] Crash/assertion failure after "RWLock failed to attach to the InfiniDB-shm-00020000 shared mem segment, got Permission denied" Created: 2020-08-31  Updated: 2021-04-19  Resolved: 2020-09-15

Status: Closed
Project: MariaDB ColumnStore
Component/s: None
Affects Version/s: 1.5.3
Fix Version/s: 5.4.1

Type: Bug Priority: Major
Reporter: Valerii Kravchuk Assignee: Daniel Lee (Inactive)
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates
relates to MCOL-4012 Enable ColumnStore to run as a non ro... Closed
Sprint: 2020-8

 Description   

Assertion failure happens after the RWLock failure reported:

2020-08-28 17:46:08 0 [Note] /usr/sbin/mariadbd: ready for connections.
Version: '10.5.4-2-MariaDB-enterprise-log'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  MariaDB Enterprise Server
2020-08-28 17:46:11 0 [Note] InnoDB: Buffer pool(s) load completed at 200828 17:46:11
RWLock failed to attach to the InfiniDB-shm-00020000 shared mem segment, got Permission denied
ControllerSegmentTable: RWLock() threw: Permission denied
terminate called after throwing an instance of 'boost::interprocess::interprocess_exception'
  what():  Permission denied
200828 18:08:30 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
 
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
 
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
 
Server version: 10.5.4-2-MariaDB-enterprise-log
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=2
max_threads=153
thread_count=4
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467809 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0x7fe5f00009b8
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x7feeb015fc90 thread_stack 0x49000
??:0(my_print_stacktrace)[0x5604334473ae]
??:0(handle_fatal_signal)[0x560432e213e7]
sigaction.c:0(__restore_rt)[0x7feedbc65630]
:0(__GI_raise)[0x7feed9d2e377]
:0(__GI_abort)[0x7feed9d2fa68]
??:0(__gnu_cxx::__verbose_terminate_handler())[0x7feeda4287d5]
??:0(std::rethrow_exception(std::__exception_ptr::exception_ptr))[0x7feeda426746]
??:0(std::terminate())[0x7feeda426773]
??:0(std::terminate())[0x7feeda426786]
??:0(__cxa_call_unexpected)[0x7feeda4263c2]
??:0(BRM::DBRM::DBRM(bool))[0x7feec36e63a2]
??:0(execplan::SessionManager::SessionManager())[0x7feec51b28a0]
??:0(execplan::CalpontSystemCatalog::CalpontSystemCatalog())[0x7feec5172cc5]
??:0(execplan::CalpontSystemCatalog::makeCalpontSystemCatalog(unsigned int))[0x7feec5173448]
??:0(ha_cs_impl_pushdown_init(mcs_handler_info*, TABLE*))[0x7feed196c33f]
??:0(ha_columnstore_select_handler::init_scan())[0x7feed19512a8]
??:0(Pushdown_select::execute())[0x560432c9e44c]
??:0(JOIN::exec_inner())[0x560432c7f8bc]
?:0(JOIN::exec())[0x560432c80483]
??:0(mysql_select(THD*, TABLE_LIST*, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*))[0x560432c7e646]
??:0(handle_select(THD*, LEX*, select_result*, unsigned long))[0x560432c7f1ac]
/usr/sbin/mariadbd(+0x62ce1b)[0x560432ae4e1b]
??:0(mysql_execute_command(THD*))[0x560432c23c6c]
??:0(mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool))[0x560432c26c22]
??:0(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool))[0x560432c28fbc]
??:0(do_command(THD*))[0x560432c2a96b]
??:0(do_handle_one_connection(CONNECT*, bool))[0x560432d15109]
??:0(handle_one_connection)[0x560432d153a4]
??:0(MyCTX_nopad::finish(unsigned char*, unsigned int*))[0x560433093c3d]
pthread_create.c:0(start_thread)[0x7feedbc5dea5]
??:0(__clone)[0x7feed9df68cd]
 
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x7fe5f0114148): select  `schema`, TABLENAME, COLUMNNAME COLNAME, OBJECTID, DICTOBJECTID DICT,   case datatype when 0 then 'BIT'                 when 1 then 'TINYINT'                when 2 then 'CHAR'                when 3 then 'SMALLINT'                when 4 then 'DECIMAL'                when 5 then 'MEDINT'                when 6 then 'INT'                when 7 then 'FLOAT'                when 8 then 'DATE'                when 9 then 'BIGINT'                when 10 then 'DOUBLE'                when 11 then 'DATETIME'                when 12 then 'VARCHAR'                when 13 then 'CLOB'                when 14 then 'BLOB'                when 15 then 'TEXT'                end DATATYPE,   SCALE, PREC, COLUMNLENGTH COLLEN, COLUMNPOSITION POS, COMPRESSIONTYPE CT from  syscolumn order by  `schema`, TABLENAME, POS
Connection ID (thread ID): 1182
Status: NOT_KILLED
...



 Comments   
Comment by Todd Stoffel (Inactive) [ 2020-09-04 ]

https://www.boost.org/doc/libs/1_74_0/doc/html/boost/interprocess/permissions.html

Comment by David Hall (Inactive) [ 2020-09-11 ]

QA:
This problem should be cleared up after MCOL-4012 is in.
To test:

systemctl stop mariadb
systemctl stop mariadb-columnstore
systemctl start mariadb-columnstore

chmod 644 /dev/shm/*

systemctl start mariadb

Run queries
Before MCOL-4012, it should assert as above. After MCOL-4012, queries should work as expected.

Comment by Daniel Lee (Inactive) [ 2020-09-15 ]

Build verified: 1.5.4-1 (drone #635)

The permission on /dev/shm is now 777.
Tested along with testing on MCOL-4012.

Generated at Thu Feb 08 02:49:11 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.