[MDEV-14697] Server crashes in in TABLE::mark_default_fields_for_write Created: 2017-12-17  Updated: 2018-08-20  Resolved: 2018-08-20

Status: Closed
Project: MariaDB Server
Component/s: Data Definition - Alter Table, Data Manipulation - Insert
Affects Version/s: 10.2, 10.3
Fix Version/s: 10.2.15, 10.3.7

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-15746 ASAN heap-use-after-free in Item_chan... Closed

 Description    

CREATE TABLE t1 (
 
  a CHAR(8) CHARACTER SET utf8,
 
  b TEXT CHARACTER SET utf8 DEFAULT ''
 
);
 
 
 
--error ER_KEY_COLUMN_DOES_NOT_EXITS
 
ALTER TABLE t1 ADD KEY(non_existing_col);
 
 
 
INSERT INTO t1 (a) VALUES ('foo');
 
 
 
# Cleanup
 
DROP TABLE t1;

10.2 a3476a5de2ee87

 
#3  <signal handler called>
 
#4  0x00005593ee38919f in TABLE::mark_default_fields_for_write (this=0x7fcbdc00a2c0, is_insert=true) at /data/src/10.2/sql/table.cc:6692
 
#5  0x00005593ee38871f in TABLE::mark_columns_needed_for_insert (this=0x7fcbdc00a2c0) at /data/src/10.2/sql/table.cc:6412
 
#6  0x00005593ee2591ee in mysql_insert (thd=0x7fcbdc000b00, table_list=0x7fcbdc0125d8, fields=..., values_list=..., update_fields=..., update_values=..., duplic=DUP_ERROR, ignore=false) at /data/src/10.2/sql/sql_insert.cc:904
 
#7  0x00005593ee280f4f in mysql_execute_command (thd=0x7fcbdc000b00) at /data/src/10.2/sql/sql_parse.cc:4414
 
#8  0x00005593ee28bea2 in mysql_parse (thd=0x7fcbdc000b00, rawbuf=0x7fcbdc0124e8 "INSERT INTO t1 (a) VALUES ('foo')", length=33, parser_state=0x7fcbecde3200, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:7896
 
#9  0x00005593ee279dd4 in dispatch_command (command=COM_QUERY, thd=0x7fcbdc000b00, packet=0x7fcbdc170451 "INSERT INTO t1 (a) VALUES ('foo')", packet_length=33, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1805
 
#10 0x00005593ee278732 in do_command (thd=0x7fcbdc000b00) at /data/src/10.2/sql/sql_parse.cc:1360
 
#11 0x00005593ee3c6351 in do_handle_one_connection (connect=0x5593f0dd4110) at /data/src/10.2/sql/sql_connect.cc:1354
 
#12 0x00005593ee3c60de in handle_one_connection (arg=0x5593f0dd4110) at /data/src/10.2/sql/sql_connect.cc:1260
 
#13 0x00005593ee7e4a76 in pfs_spawn_thread (arg=0x5593f0d33000) at /data/src/10.2/storage/perfschema/pfs.cc:1863
 
#14 0x00007fcbf47de494 in start_thread (arg=0x7fcbecde4700) at pthread_create.c:333
 
#15 0x00007fcbf2bc493f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Reproducible with MyISAM, Aria, InnoDB.
Not reproducible on 10.1.

 Comments   
Comment by Elena Stepanova [ 2018-07-24 ]

It doesn't seem to be reproducible anymore (as of 10.3 141a5b2484, 10.2 9827c5e10 at least). There have been plenty of fixes in the area. I'll check when this got fixed.

Comment by Elena Stepanova [ 2018-08-20 ]

The problem was fixed by this commit:

commit 92a13148e80c30422ae5460032169cbe1946fa6d
 
Author: Sergei Golubchik
 
Date:   Mon Apr 16 23:14:28 2018 +0200
 
 
 
    MDEV-15746 ASAN heap-use-after-free in Item_change_list::rollback_item_tree_changes on ALTER executed as PS
 
    
    don't try to convert a default value string from a user character set
 
    into a column character set, if this particular default value string did
 
    not came from the user at all (that is, if it's an ALTER TABLE and the
 
    default value string is the *old* default value of the unaltered
 
    column).
 
    
    This used to crash, because old defaults are allocated on the old
 
    table's memroot, which is freed mid-ALTER when the old table is closed.
 
    So thd->rollback_item_tree_changes() at the end of the ALTER was writing
 
    into the freed memory.

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