[MDEV-19697] MariaDB crash/signal 11 when performing 'use information_schema' expression Created: 2019-06-05  Updated: 2019-06-12  Resolved: 2019-06-05

Status: Closed
Project: MariaDB Server
Component/s: Server
Affects Version/s: 10.3.15
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Al Ryz Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Environment:

CentOS-7.6
Docker


Issue Links:
Duplicate
is duplicated by MDEV-19490 show tables fails when selecting the ... Closed

 Description   

When i'm trying to perform 'use information_schema' expression, MariaDB-10.3.15 goes down and writes next information to log:

190605 11:57:46 [ERROR] mysqld got signal 11 ;
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.3.15-MariaDB-log
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=1
max_threads=42
thread_count=9
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 223386 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0x7f0cdc036598
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 = 0x7f0cf04d4d30 thread_stack 0x49000
/usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x558d9679d91e]
/usr/sbin/mysqld(handle_fatal_signal+0x30f)[0x558d9623a53f]
/lib64/libpthread.so.0(+0xf5d0)[0x7f0d0d7c05d0]
/usr/sbin/mysqld(+0xd1acb7)[0x558d967d6cb7]
/usr/sbin/mysqld(_Z17find_schema_tableP3THDPK25st_mysql_const_lex_stringPb+0x55)[0x558d960d36b5]
/usr/sbin/mysqld(_Z11open_tablesP3THDRK14DDL_options_stPP10TABLE_LISTPjPP19Sroutine_hash_entryjP19Prelocking_strategy+0x942)[0x558d9600a632]
/usr/sbin/mysqld(_Z30open_normal_and_derived_tablesP3THDP10TABLE_LISTjj+0x67)[0x558d9600b217]
/usr/sbin/mysqld(_Z18mysqld_list_fieldsP3THDP10TABLE_LISTPKc+0x35)[0x558d960c3415]
/usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcjbb+0x24ad)[0x558d9606e04d]
/usr/sbin/mysqld(_Z10do_commandP3THD+0x13e)[0x558d9606e73e]
/usr/sbin/mysqld(_Z24do_handle_one_connectionP7CONNECT+0x1aa)[0x558d9613f79a]
/usr/sbin/mysqld(handle_one_connection+0x3d)[0x558d9613f8bd]
/lib64/libpthread.so.0(+0x7dd5)[0x7f0d0d7b8dd5]
/lib64/libc.so.6(clone+0x6d)[0x7f0d0bb5bead]
 
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x7f0cdc0401e0): 
Connection ID (thread ID): 10
Status: NOT_KILLED
 
Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_materialized=on

And below in log I see that coredump was generated:

Writing a core file...

But directory specified in kernel.core_pattern is empty:

sysctl kernel.core_pattern
kernel.core_pattern = /var/***/cores/core-%e-%s-%u-%g-%p-%t
 
ll /var/***/cores/
total 0

This problem also can be reproduced with official Docker image:

docker run --name mariadb-10.3.15 -e MYSQL_ROOT_PASSWORD=password -d -p 3333:3306 mariadb:10.3.15-bionic
 
mysql -uroot -ppassword -h127.0.0.1 -P3333
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 8
Server version: 10.3.15-MariaDB-1:10.3.15+maria~bionic mariadb.org binary distribution
 
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
 
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
 
MariaDB [(none)]> use information_schema
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
 
Database changed
MariaDB [information_schema]> ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
ERROR 2002 (HY000): Can't connect to MySQL server on '127.0.0.1' (115)
ERROR: Can't connect to the server

But with, for example, MariaDB-10.3.11 this problem doesn't reproduced:

docker run --name mariadb-10.3.11 -e MYSQL_ROOT_PASSWORD=password -d -p 3334:3306 mariadb:10.3.11-bionic
 
mysql -uroot -ppassword -h127.0.0.1 -P3334
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 8
Server version: 10.3.11-MariaDB-1:10.3.11+maria~bionic mariadb.org binary distribution
 
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
 
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
 
MariaDB [(none)]> use information_schema
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
 
Database changed
MariaDB [information_schema]> show tables;
+---------------------------------------+
| Tables_in_information_schema|
+---------------------------------------+
| ALL_PLUGINS                           |
| APPLICABLE_ROLES                  |
| CHARACTER_SETS                      |
| CHECK_CONSTRAINTS               |
| COLLATIONS                             |
| COLUMNS                                 |
+---------------------------------------+
...
76 rows in set (0.001 sec)



 Comments   
Comment by Elena Stepanova [ 2019-06-05 ]

Thanks.

This problem has been fixed in the scope of MDEV-19490, the fix will be included into the next releases.

Comment by Al Ryz [ 2019-06-05 ]

Sorry for duplicated task. I didn't find MDEV-19490 when reporting this problem.

Comment by Elena Stepanova [ 2019-06-05 ]

I understand. It's one of generic failures which isn't easy to search for in JIRA.

Generated at Thu Feb 08 08:53:40 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.