Bug #80062 Assertion `trx->undo_no == 0' failed in innobase/handler/handler0alter.cc:7349
Submitted: 20 Jan 2016 5:35 Modified: 20 Jan 2016 14:51
Reporter: Ramesh Sivaraman Email Updates:
Status: Duplicate Impact on me:
None 
Category:MySQL Server: InnoDB storage engine Severity:S3 (Non-critical)
Version:5.7.10, 5.7.12 OS:CentOS (CentOS7)
Assigned to: CPU Architecture:Any
Tags: debug

[20 Jan 2016 5:35] Ramesh Sivaraman
Description:
#0  0x00007f5982e2c741 in pthread_kill () from /lib64/libpthread.so.0
#1  0x00000000017ef51c in my_write_core (sig=6) at /sda/mysql-server_dbg/mysys/stacktrace.c:247
#2  0x0000000000e583e4 in handle_fatal_signal (sig=6) at /sda/mysql-server_dbg/sql/signal_handler.cc:220
#3  <signal handler called>
#4  0x00007f5980fb95f7 in raise () from /lib64/libc.so.6
#5  0x00007f5980fbace8 in abort () from /lib64/libc.so.6
#6  0x00007f5980fb2566 in __assert_fail_base () from /lib64/libc.so.6
#7  0x00007f5980fb2612 in __assert_fail () from /lib64/libc.so.6
#8  0x000000000195e9ba in commit_try_norebuild (ha_alter_info=0x7f59833df8c0, ctx=0x7f594582cef0, altered_table=0x7f5945951e20, old_table=0x7f594585ba20, trx=0x7f5976000cf8, table_name=0x7f59458373e5 "child") at /sda/mysql-server_dbg/storage/innobase/handler/handler0alter.cc:7349
#9  0x000000000195a67a in ha_innobase::commit_inplace_alter_table (this=0x7f59458aa030, altered_table=0x7f5945951e20, ha_alter_info=0x7f59833df8c0, commit=true) at /sda/mysql-server_dbg/storage/innobase/handler/handler0alter.cc:7917
#10 0x0000000000ed8913 in handler::ha_commit_inplace_alter_table (this=0x7f59458aa030, altered_table=0x7f5945951e20, ha_alter_info=0x7f59833df8c0, commit=true) at /sda/mysql-server_dbg/sql/handler.cc:4679
#11 0x0000000001574814 in mysql_inplace_alter_table (thd=0x7f5945819000, table_list=0x7f594582baa0, table=0x7f594585ba20, altered_table=0x7f5945951e20, ha_alter_info=0x7f59833df8c0, inplace_supported=HA_ALTER_INPLACE_NO_LOCK_AFTER_PREPARE, target_mdl_request=0x7f59833df300, alter_ctx=0x7f59833dfe50) at /sda/mysql-server_dbg/sql/sql_table.cc:7358
#12 0x0000000001579487 in mysql_alter_table (thd=0x7f5945819000, new_db=0x7f594582c028 "test", new_name=0x0, create_info=0x7f59833e0ce0, table_list=0x7f594582baa0, alter_info=0x7f59833e0c30) at /sda/mysql-server_dbg/sql/sql_table.cc:9383
#13 0x00000000016cf91b in Sql_cmd_alter_table::execute (this=0x7f594582c288, thd=0x7f5945819000) at /sda/mysql-server_dbg/sql/sql_alter.cc:316
#14 0x00000000014e960d in mysql_execute_command (thd=0x7f5945819000, first_level=true) at /sda/mysql-server_dbg/sql/sql_parse.cc:4796
#15 0x00000000014eb3dd in mysql_parse (thd=0x7f5945819000, parser_state=0x7f59833e2560) at /sda/mysql-server_dbg/sql/sql_parse.cc:5508
#16 0x00000000014e0d17 in dispatch_command (thd=0x7f5945819000, com_data=0x7f59833e2cb0, command=COM_QUERY) at /sda/mysql-server_dbg/sql/sql_parse.cc:1425
#17 0x00000000014dfbe1 in do_command (thd=0x7f5945819000) at /sda/mysql-server_dbg/sql/sql_parse.cc:993
#18 0x000000000160adc7 in handle_connection (arg=0x7f59703fce00) at /sda/mysql-server_dbg/sql/conn_handler/connection_handler_per_thread.cc:301
#19 0x000000000188e1b8 in pfs_spawn_thread (arg=0x7f59607ef220) at /sda/mysql-server_dbg/storage/perfschema/pfs.cc:2192
#20 0x00007f5982e27dc5 in start_thread () from /lib64/libpthread.so.0
#21 0x00007f598107a21d in clone () from /lib64/libc.so.6

How to repeat:
Testcase

DROP DATABASE test;CREATE DATABASE test;USE test;
CREATE TABLE child(a1 INT KEY,a2 INT)ENGINE=InnoDB;
SET @@session.foreign_key_checks=DEFAULT;
set global innodb_trx_rseg_n_slots_debug=1;
CREATE TABLE t2(c1 CHAR (1));# 
CREATE TABLE t1(c1 TIME,c2 BINARY(1),c3 INT(1),c4 BINARY(1) KEY,c5 TIME UNIQUE KEY,c6 DEC(0,0) DEFAULT 3.141592);
ALTER TABLE child ADD CONSTRAINT fk_4 FOREIGN KEY(a1,a2)REFERENCES parent(a,b) ON DELETE CASCADE ON UPDATE CASCADE,ALGORITHM=INPLACE;

The attached tarball (1452772996_bug_bundle.tar.gz) gives the testcase as an exact match of our system, including some handy utilities

$ vi 1452772996_mybase     # STEP1: Update the base path in this file (usually the only change required!). If you use a non-binary distribution, please update SOURCE_DIR location also
$ ./1452772996_init        # STEP2: Initializes the data dir
$ ./1452772996_start       # STEP3: Starts mysqld
$ ./1452772996_cl          # STEP4: To check mysqld is up
$ ./1452772996_run_pquery  # STEP5: Run the testcase with the pquery binary
$ ./1452772996_run         # OPTIONAL: Run the testcase with the mysql CLI (may not reproduce the issue, as the pquery binary was used for the original testcase reduction)
$ vi /dev/shm/1452772996/error.log.out  # STEP6: Verify the error log
$ ./1452772996_gdb         # OPTIONAL: Brings you to a gdb prompt with gdb attached to the used mysqld and attached to the generated core
$ ./1452772996_parse_core  # STEP7: Creates 1452772996_STD.gdb and 1452772996_FULL.gdb; standard and full variables gdb stack traces
[20 Jan 2016 5:40] Ramesh Sivaraman
Bug bundle

Attachment: 1452772996_bug_bundle.tar.gz (application/gzip, text), 2.01 MiB.

[20 Jan 2016 5:41] Ramesh Sivaraman
Similar to Bug#74862 Bug#74363
[20 Jan 2016 5:55] MySQL Verification Team
Hello Ramesh,

Thank you for the report and test case.
Observed that 5.7.10/5.7.12 debug build is affected.

Thanks,
Umesh
[20 Jan 2016 14:38] Naga Satyanarayana Bodapati
Posted by developer:
 
This bug is mostly theoretical bug because of the debug variable  innodb_trx_rseg_n_slots_debug.

Was able to reproduce the problem in 5.6 as well.

It is duplicate of BUG#19947739 ( although the failing assertions are different).

The underlying cause is same. "DDLs are known to corrupt SYS_TABLES when they cannot get undo slot. This can happen only when there are 128k concurrent transactions". So I suggest to close all bugs related to "set global innodb_trx_rseg_n_slots_debug=1;" and DDLs
[20 Jan 2016 14:43] Naga Satyanarayana Bodapati
We will see innodb throw warnings like this when it reaches the max concurrent transaction limit.

 InnoDB: Warning: cannot find a free slot for an undo log. Do you have too
InnoDB: many active transactions running concurrently?

At this stage, ALTERs will not succeed and may corrupt the database. But this will be seen only when you reach the max concurrent tranasactions limit (128K?)
[20 Jan 2016 14:51] Naga Satyanarayana Bodapati
This is duplicate of BUG#74363