Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Duplicate
-
10.4.13
Description
The attached sql scripts (generated from alembic migrations) which worked fine in previous versions (and the latest 10.5.x) of MariaDB server cause a segfault in 10.4.13.
Environment:
| OS | Debian buster |
| Kernel | 5.4.0-42, 4.15.0-109 |
| HW | Intel 64-bit, with docker 19.03.12 under Ubuntu 20.04 or 18.04 |
| MariaDB | 10.4.13 |
Error message:
200804 5:05:51 [ERROR] mysqld got signal 11 ;
|
...
|
We think the query pointer is invalid, but we will try to print it anyway.
|
Query: ALTER TABLE albums ADD CONSTRAINT albums_fk1 FOREIGN KEY(list_id) REFERENCES lists (id)
|
My.cnf
[mysqld]
|
#
|
# * Basic Settings
|
#
|
basedir = /usr
|
tmpdir = /tmp
|
skip-external-locking
|
character_set_server = utf8
|
ignore_db_dirs = lost+found
|
|
|
#
|
# * Fine Tuning
|
#
|
ft_min_word_len = 3
|
join_buffer_size = 131072
|
key_buffer_size = 16M
|
max_allowed_packet = 256M
|
#max_connections = 100
|
max_heap_table_size = 16M
|
query_cache_type = OFF
|
query_cache_size = 0
|
read_buffer_size = 131072
|
read_rnd_buffer_size = 262144
|
table_open_cache = 4096
|
thread_stack = 192K
|
thread_cache_size = 8
|
#thread_concurrency = 12
|
tmp_table_size = 16M
|
|
|
interactive_timeout = 28800
|
net_read_timeout = 30
|
net_write_timeout = 60
|
wait_timeout = 3600
|
|
|
#
|
# * Slow query log
|
#
|
slow_query_log_file = /var/log/mysql/mysql-slow.log
|
slow_query_log = 1
|
long_query_time = 4
|
#log_queries_not_using_indexes
|
|
|
#
|
# * InnoDB
|
#
|
innodb_data_file_path = ibdata1:10M:autoextend
|
innodb_buffer_pool_instances = 1
|
innodb_buffer_pool_size = 1024M
|
innodb_log_file_size = 32M
|
Additional info:
The Dockerfile I use to test and verify this is at: instantlinux/mariadb-galera Dockerfile
An image built (from the stock debian binary package) that exhibits this problem under Docker is published to instantlinux/mariadb-galera:10.4.13 on dockerhub.
To reproduce, CREATE DATABASE, then run the first.sql and crash_it.sql files.
Full dump of error:
200804 5:05:51 [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.4.13-MariaDB-1:10.4.13+maria~buster-log
|
key_buffer_size=16777216
|
read_buffer_size=131072
|
max_used_connections=3
|
max_threads=153
|
thread_count=18
|
It is possible that mysqld could use up to
|
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 353068 K bytes of memory
|
Hope that's ok; if not, decrease some variables in the equation.
|
|
|
Thread pointer: 0x7f6934000e78
|
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 = 0x7f69e40ccdd8 thread_stack 0x30000
|
/usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x5627800f18de]
|
/usr/sbin/mysqld(handle_fatal_signal+0x54d)[0x56277fbe9c4d]
|
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12730)[0x7f6a16239730]
|
|
|
Trying to get some variables.
|
Some pointers may be invalid and cause the dump to abort.
|
Query (0x7f6934010270): is an invalid pointer
|
Connection ID (thread ID): 160
|
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=on,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_materialized=on,condition_pushdown_for_subquery=on,rowid_filter=on,condition_pushdown_from_having=on
|
|
|
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
|
information that should help you find out what is causing the crash.
|
|
|
We think the query pointer is invalid, but we will try to print it anyway.
|
Query: ALTER TABLE albums ADD CONSTRAINT albums_fk1 FOREIGN KEY(list_id) REFERENCES lists (id)
|
|
|
Writing a core file...
|
Working directory at /var/lib/mysql
|
Resource Limits:
|
Limit Soft Limit Hard Limit Units
|
Max cpu time unlimited unlimited seconds
|
Max file size unlimited unlimited bytes
|
Max data size unlimited unlimited bytes
|
Max stack size 8388608 unlimited bytes
|
Max core file size unlimited unlimited bytes
|
Max resident set unlimited unlimited bytes
|
Max processes unlimited unlimited processes
|
Max open files 1048576 1048576 files
|
Max locked memory 65536 65536 bytes
|
Max address space unlimited unlimited bytes
|
Max file locks unlimited unlimited locks
|
Max pending signals 127370 127370 signals
|
Max msgqueue size 819200 819200 bytes
|
Max nice priority 0 0
|
Max realtime priority 0 0
|
Max realtime timeout unlimited unlimited us
|
Core pattern: |/usr/share/apport/apport %p %s %c %d %P ...
|
Attachments
Issue Links
- duplicates
-
-
- Closed
-
Activity
I can repeat the failure with the parent of the fix of MDEV-22563 but not after that. That fix was part of the MariaDB 10.5.4 release.
I can repeat the crash on MariaDB 10.4.13 both with and without AddressSanitizer:
mariadb-10.4.13
mysqltest: At line 405: query 'ALTER TABLE albums ADD COLUMN list_id VARCHAR(16)' failed: 2013: Lost connection to MySQL server during query…Version: '10.4.13-MariaDB-debug-log' socket: '/dev/shm/10.4/mysql-test/var/tmp/mysqld.1.sock' port: 16000 Source distribution===================================================================287751==ERROR: AddressSanitizer: heap-use-after-free on address 0x61d0003483f8 at pc 0x0000016d8ced bp 0x7fd128edab10 sp 0x7fd128edab08READ of size 8 at 0x61d0003483f8 thread T27#0 0x16d8cec in Item_func_in::cleanup() /mariadb/10.4/sql/item_cmpfunc.h:2414:5#1 0x923399 in Item::delete_self() /mariadb/10.4/sql/item.h:2182:5#2 0x923399 in Query_arena::free_items() /mariadb/10.4/sql/sql_class.cc:3779:16#3 0x922e2a in THD::cleanup_after_query() /mariadb/10.4/sql/sql_class.cc:2279:3#4 0xa3e0b4 in mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool) /mariadb/10.4/sql/sql_parse.cc:7923:10#5 0xa35aca in dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool) /mariadb/10.4/sql/sql_parse.cc:1841:7#6 0xa3f4ab in do_command(THD*) /mariadb/10.4/sql/sql_parse.cc:1359:17#7 0xe12a13 in do_handle_one_connection(CONNECT*) /mariadb/10.4/sql/sql_connect.cc:1412:11#8 0xe12323 in handle_one_connection /mariadb/10.4/sql/sql_connect.cc:1316:3#9 0x2644d95 in pfs_spawn_thread /mariadb/10.4/storage/perfschema/pfs.cc:1869:3#10 0x7fd14009cea6 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x8ea6)#11 0x7fd13f6f5dae in clone (/lib/x86_64-linux-gnu/libc.so.6+0xfddae)0x61d0003483f8 is located 888 bytes inside of 1976-byte region [0x61d000348080,0x61d000348838)freed by thread T27 here:#0 0x70e4ad in free (/dev/shm/10.4/sql/mysqld+0x70e4ad)#1 0x2782e04 in my_free /mariadb/10.4/mysys/my_malloc.c:222:5#2 0x2766ffd in free_root /mariadb/10.4/mysys/my_alloc.c:429:7#3 0xd536a6 in closefrm(TABLE*) /mariadb/10.4/sql/table.cc:4076:3#4 0x106abb5 in intern_close_table(TABLE*) /mariadb/10.4/sql/table_cache.cc:221:3#5 0x106c7ce in tc_release_table(TABLE*) /mariadb/10.4/sql/table_cache.cc:471:5#6 0x8b42f5 in close_thread_table(THD*, TABLE**) /mariadb/10.4/sql/sql_base.cc:1078:3#7 0x8b13a6 in close_all_tables_for_name(THD*, TABLE_SHARE*, ha_extra_function, TABLE*) /mariadb/10.4/sql/sql_base.cc:842:7#8 0xcc3a1f in mysql_inplace_alter_table(THD*, TABLE_LIST*, TABLE*, TABLE*, Alter_inplace_info*, enum_alter_inplace_result, MDL_request*, Alter_table_ctx*) /mariadb/10.4/sql/sql_table.cc:7783:3#9 0xcc3a1f in mysql_alter_table(THD*, st_mysql_const_lex_string const*, st_mysql_const_lex_string const*, HA_CREATE_INFO*, TABLE_LIST*, Alter_info*, unsigned int, st_order*, bool) /mariadb/10.4/sql/sql_table.cc:10130:16#10 0xe284d4 in Sql_cmd_alter_table::execute(THD*) /mariadb/10.4/sql/sql_alter.cc:514:11#11 0xa4d48e in mysql_execute_command(THD*) /mariadb/10.4/sql/sql_parse.cc:6101:26#12 0xa3de72 in mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool) /mariadb/10.4/sql/sql_parse.cc:7900:18#13 0xa35aca in dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool) /mariadb/10.4/sql/sql_parse.cc:1841:7#14 0xa3f4ab in do_command(THD*) /mariadb/10.4/sql/sql_parse.cc:1359:17#15 0xe12a13 in do_handle_one_connection(CONNECT*) /mariadb/10.4/sql/sql_connect.cc:1412:11#16 0xe12323 in handle_one_connection /mariadb/10.4/sql/sql_connect.cc:1316:3previously allocated by thread T27 here:#0 0x70e72d in malloc (/dev/shm/10.4/sql/mysqld+0x70e72d)#1 0x2782a64 in my_malloc /mariadb/10.4/mysys/my_malloc.c:101:10#2 0x2766228 in alloc_root /mariadb/10.4/mysys/my_alloc.c:250:30#3 0x9ef587 in Item::operator new(unsigned long, st_mem_root*) /mariadb/10.4/sql/item.h:739:12#4 0x9ef587 in LEX::create_item_ident_field(THD*, char const*, char const*, Lex_ident_sys_st const*) /mariadb/10.4/sql/sql_lex.cc:7543:12#5 0x6060000000a0 (<unknown module>)However, neither the currently latest 10.4 100f0c965cbbcf5a0f665bd233fdfab33544c774 nor the likely mariadb-10.4.14 release 57325e470615e79f674d82b2d5b09f609508fc6a seem to be affected.