[MDEV-23396] Segfault in ALTER TABLE Created: 2020-08-04  Updated: 2020-08-04  Resolved: 2020-08-04

Status: Closed
Project: MariaDB Server
Component/s: Data Definition - Alter Table
Affects Version/s: 10.4.13
Fix Version/s: 10.5.4, 10.4.14

Type: Bug Priority: Major
Reporter: Rich Braun Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: ASAN, crash

Attachments: File crash_it.sql     File first.sql    
Issue Links:
Duplicate
duplicates MDEV-22563 Segfault on duplicate free of Item_f... Closed

 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 ...



 Comments   
Comment by Marko Mäkelä [ 2020-08-04 ]

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 0x7fd128edab08
READ 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:3
 
previously 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.

Comment by Marko Mäkelä [ 2020-08-04 ]

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.

Generated at Thu Feb 08 09:22:05 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.