Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.1(EOL)
-
None
Description
Run with --repeat if it doesn't fail right away.
--source include/have_innodb.inc
|
|
|
--connect (con1,localhost,root,,test)
|
CREATE TABLE t1 (pk INT PRIMARY KEY) ENGINE=InnoDB; |
INSERT INTO t1 VALUES (45852),(19898),(55954); |
CREATE TABLE t2 (pk INT PRIMARY KEY, FOREIGN KEY (pk) REFERENCES t1 (pk) ON DELETE CASCADE ON UPDATE CASCADE) ENGINE=InnoDB; |
--send
|
ALTER TABLE t1 FORCE; |
|
|
--connection default
|
ALTER TABLE t2 FORCE; |
|
|
# Cleanup
|
|
|
--connection con1
|
--reap
|
--disconnect con1
|
--connection default
|
DROP TABLE t2, t1; |
|
10.1 36ea82617c |
2018-07-02 0:48:46 140626074102528 [ERROR] InnoDB: dict_load_foreigns() returned 38 for ALTER TABLE t2 FORCE
|
2018-07-02 00:48:46 7fe60f316b00 InnoDB: Assertion failure in thread 140626074102528 in file handler0alter.cc line 6163
|
InnoDB: Failing assertion: 0
|
|
|
#5 0x00007fe60d2aa3fa in abort () from /lib/x86_64-linux-gnu/libc.so.6
|
#6 0x00007fe60671c3c4 in ha_innodb::commit_inplace_alter_table (this=0x7fe5f70b0888, altered_table=0x7fe5f71e7070, ha_alter_info=0x7fe60f312b00, commit=true) at /data/src/10.1/storage/innobase/handler/handler0alter.cc:6163
|
#7 0x000055c2322fd991 in handler::ha_commit_inplace_alter_table (this=0x7fe5f70b0888, altered_table=0x7fe5f71e7070, ha_alter_info=0x7fe60f312b00, commit=true) at /data/src/10.1/sql/handler.cc:4222
|
#8 0x000055c23217a0cc in mysql_inplace_alter_table (thd=0x7fe603bc7070, table_list=0x7fe5f7043160, table=0x7fe5f7081c70, altered_table=0x7fe5f71e7070, ha_alter_info=0x7fe60f312b00, inplace_supported=HA_ALTER_INPLACE_NO_LOCK_AFTER_PREPARE, target_mdl_request=0x7fe60f312b70, alter_ctx=0x7fe60f313710) at /data/src/10.1/sql/sql_table.cc:7222
|
#9 0x000055c23217ea3c in mysql_alter_table (thd=0x7fe603bc7070, new_db=0x7fe5f7043750 "test", new_name=0x0, create_info=0x7fe60f314300, table_list=0x7fe5f7043160, alter_info=0x7fe60f314270, order_num=0, order=0x0, ignore=false) at /data/src/10.1/sql/sql_table.cc:9048
|
#10 0x000055c2321efc9b in Sql_cmd_alter_table::execute (this=0x7fe5f7043758, thd=0x7fe603bc7070) at /data/src/10.1/sql/sql_alter.cc:325
|
#11 0x000055c2320bf441 in mysql_execute_command (thd=0x7fe603bc7070) at /data/src/10.1/sql/sql_parse.cc:5696
|
#12 0x000055c2320c3bcb in mysql_parse (thd=0x7fe603bc7070, rawbuf=0x7fe5f7043088 "ALTER TABLE t2 FORCE", length=20, parser_state=0x7fe60f3155e0) at /data/src/10.1/sql/sql_parse.cc:7449
|
#13 0x000055c2320b2605 in dispatch_command (command=COM_QUERY, thd=0x7fe603bc7070, packet=0x7fe605ac3071 "ALTER TABLE t2 FORCE", packet_length=20) at /data/src/10.1/sql/sql_parse.cc:1492
|
#14 0x000055c2320b138a in do_command (thd=0x7fe603bc7070) at /data/src/10.1/sql/sql_parse.cc:1121
|
#15 0x000055c2321eb22d in do_handle_one_connection (thd_arg=0x7fe603bc7070) at /data/src/10.1/sql/sql_connect.cc:1330
|
#16 0x000055c2321eaf91 in handle_one_connection (arg=0x7fe603bc7070) at /data/src/10.1/sql/sql_connect.cc:1242
|
#17 0x000055c2325a8452 in pfs_spawn_thread (arg=0x7fe607ff2670) at /data/src/10.1/storage/perfschema/pfs.cc:1861
|
#18 0x00007fe60efa5494 in start_thread (arg=0x7fe60f316b00) at pthread_create.c:333
|
#19 0x00007fe60d35e93f in clone () from /lib/x86_64-linux-gnu/libc.so.6
|
Couldn't reproduce on 10.0 or 10.2.
No obvious problems on a non-debug build.
Search for the error 38 in dict_load_foreigns gave me only one result:
https://bugs.launchpad.net/percona-server/+bug/1385060 . The test case from this bug report doesn't fail for me, though.
This bug points at the upstream bug https://bugs.mysql.com/bug.php?id=74363 .
However, that bug describes a different error in a different place. I suppose there was a reason why the Percona entry says it's the same, but this reason is unknown to me. I hope marko will remember it, as he was looking into the upstream issue at the time.
Attachments
Issue Links
- duplicates
-
-
- Closed
-
- relates to
-
-
- Confirmed
-
-
-
- Closed
-
Activity
The strange thing about Percona / MySQL bugs is that the initial test case by Ramesh Sivaraman doesn't mention innodb_trx_rseg_n_slots_debug at all. But that test case doesn't fail for me on MariaDB. The debug variable only comes up later, when Shane re-wrote the test case, and the Roel says that they use it a lot; so I don't know, maybe it's implied that the initial test case should be run with a certain value of the variable.
See also MDEV-18321 which has a very similar crash and what appears to be a deterministic test case, but with virtual columns.
MySQL Bug #74363 is something else and should affect MariaDB too. It is about running out of space for undo log during a DDL transaction.
I can repeat this with the parent of the commit that fixed MDEV-18016 but not when that fix is present.
MDEV-18016 is also fixing MDEV-18321.
Based on a look at the code, 38 should be DB_CANNOT_ADD_CONSTRAINT. I did not debug this yet.
This looks different from the mentioned Percona and MySQL bugs, because that test case is injecting a fault (making the undo log allocation fail) by setting the global variable innodb_trx_rseg_n_slots_debug. It is a known issue that if InnoDB fails to allocate an undo log page during ALTER TABLE or DROP INDEX or similar, the entire table may be lost. In MariaDB, this problem would be addressed by MDEV-11655.