[MDEV-16903] Assertion `!auto_increment_field_not_null' failed in TABLE::init after unsuccessful attempt to add CHECK constraint on temporary table Created: 2018-08-05  Updated: 2019-01-19  Resolved: 2018-12-20

Status: Closed
Project: MariaDB Server
Component/s: Data Definition - Alter Table, Data Definition - Temporary
Affects Version/s: 10.2, 10.3
Fix Version/s: 10.2.20, 10.3.12

Type: Bug Priority: Critical
Reporter: Elena Stepanova Assignee: Sergei Golubchik
Resolution: Fixed Votes: 0
Labels: affects-tests

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

 Description   

CREATE TEMPORARY TABLE t1 (
  id INT NOT NULL AUTO_INCREMENT,
  f INT NOT NULL DEFAULT 0,
  PRIMARY KEY (id)
);
INSERT INTO t1 () VALUES ();
ALTER IGNORE TABLE t1 ADD CONSTRAINT CHECK (f > 0);
ALTER TABLE t1;

10.2 affdd79c6

mysqld: /data/src/10.2/sql/table.cc:4514: void TABLE::init(THD*, TABLE_LIST*): Assertion `!auto_increment_field_not_null' failed.
180805 21:27:27 [ERROR] mysqld got signal 6 ;
 
#7  0x00007fd836f2eee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
#8  0x000056238732a502 in TABLE::init (this=0x7fd820173290, thd=0x7fd820000b00, tl=0x7fd820012540) at /data/src/10.2/sql/table.cc:4514
#9  0x00005623874161cf in THD::open_temporary_table (this=0x7fd820000b00, tl=0x7fd820012540) at /data/src/10.2/sql/temporary_tables.cc:402
#10 0x00005623874162bf in THD::open_temporary_tables (this=0x7fd820000b00, tl=0x7fd820012540) at /data/src/10.2/sql/temporary_tables.cc:439
#11 0x0000562387221842 in mysql_execute_command (thd=0x7fd820000b00) at /data/src/10.2/sql/sql_parse.cc:3394
#12 0x000056238722fa96 in mysql_parse (thd=0x7fd820000b00, rawbuf=0x7fd820012478 "ALTER TABLE t1", length=14, parser_state=0x7fd83120a200, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:8009
#13 0x000056238721d516 in dispatch_command (command=COM_QUERY, thd=0x7fd820000b00, packet=0x7fd82008cb51 "ALTER TABLE t1", packet_length=14, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1824
#14 0x000056238721be79 in do_command (thd=0x7fd820000b00) at /data/src/10.2/sql/sql_parse.cc:1378
#15 0x000056238736d678 in do_handle_one_connection (connect=0x5623896160f0) at /data/src/10.2/sql/sql_connect.cc:1335
#16 0x000056238736d405 in handle_one_connection (arg=0x5623896160f0) at /data/src/10.2/sql/sql_connect.cc:1241
#17 0x000056238778f79a in pfs_spawn_thread (arg=0x562389634940) at /data/src/10.2/storage/perfschema/pfs.cc:1862
#18 0x00007fd838c05494 in start_thread (arg=0x7fd83120b700) at pthread_create.c:333
#19 0x00007fd836feb93f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Reproducible with at least InnoDB and MyISAM.
No obvious effect on a non-debug build.



 Comments   
Comment by Elena Stepanova [ 2018-12-10 ]

The same happens if the last statement is DML, not DDL:

CREATE TEMPORARY TABLE t1 (
  id INT NOT NULL AUTO_INCREMENT,
  f INT NOT NULL DEFAULT 0,
  PRIMARY KEY (id)
);
INSERT INTO t1 () VALUES ();
ALTER IGNORE TABLE t1 ADD CONSTRAINT CHECK (f > 0);
INSERT INTO t1 () VALUES ();

10.4 8cf7e3459d

mysqld: /data/src/10.4/sql/table.cc:4668: void TABLE::init(THD*, TABLE_LIST*): Assertion `!auto_increment_field_not_null' failed.
181210 20:57:38 [ERROR] mysqld got signal 6 ;
 
#7  0x00007fbcf83deee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
#8  0x0000562e857f2ca7 in TABLE::init (this=0x7fbce013b0b0, thd=0x7fbce0000b00, tl=0x7fbce0014ea0) at /data/src/10.4/sql/table.cc:4668
#9  0x0000562e8591838e in THD::open_temporary_table (this=0x7fbce0000b00, tl=0x7fbce0014ea0) at /data/src/10.4/sql/temporary_tables.cc:415
#10 0x0000562e8591847d in THD::open_temporary_tables (this=0x7fbce0000b00, tl=0x7fbce0014ea0) at /data/src/10.4/sql/temporary_tables.cc:452
#11 0x0000562e856db664 in mysql_execute_command (thd=0x7fbce0000b00) at /data/src/10.4/sql/sql_parse.cc:4718
#12 0x0000562e856e63bc in mysql_parse (thd=0x7fbce0000b00, rawbuf=0x7fbce0014db8 "INSERT INTO t1 () VALUES ()", length=27, parser_state=0x7fbcf2570600, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:8103
#13 0x0000562e856d35e6 in dispatch_command (command=COM_QUERY, thd=0x7fbce0000b00, packet=0x7fbce000b421 "INSERT INTO t1 () VALUES ()", packet_length=27, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1850
#14 0x0000562e856d200a in do_command (thd=0x7fbce0000b00) at /data/src/10.4/sql/sql_parse.cc:1395
#15 0x0000562e8583ddd6 in do_handle_one_connection (connect=0x562e889910a0) at /data/src/10.4/sql/sql_connect.cc:1402
#16 0x0000562e8583db5a in handle_one_connection (arg=0x562e889910a0) at /data/src/10.4/sql/sql_connect.cc:1308
#17 0x0000562e85cf6890 in pfs_spawn_thread (arg=0x562e888f1190) at /data/src/10.4/storage/perfschema/pfs.cc:1862
#18 0x00007fbcf9e9a494 in start_thread (arg=0x7fbcf2571700) at pthread_create.c:333
#19 0x00007fbcf849b93f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Comment by Elena Stepanova [ 2019-01-19 ]

The test case from the description seems to be fixed, but the test case from the comment above is not, it causes an ASAN failure now. I have a spare bug report MDEV-16905 which I thought to be the same problem as MDEV-16903, it's also not fixed, so I'll add the test case above there.

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