innodb_fake_changes cause unknown error code 1000

Bug #1410410 reported by sbester on 2015-01-13
36
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Percona Server moved to https://jira.percona.com/projects/PS
Fix Released
Medium
Krunal Bauskar
5.5
Invalid
Undecided
Unassigned
5.6
Fix Released
Medium
Krunal Bauskar

Bug Description

Version: '5.6.22-71.0' MySQL Community Server (GPL)

InnoDB: unknown error code 1000
InnoDB: Assertion failure in thread X in file row0mysql.cc line 688

Program received signal SIGABRT, Aborted.
 in raise () from /usr/lib64/libc.so.6
(gdb) bt
#0 in raise () from /usr/lib64/libc.so.6
#1 in abort () from /usr/lib64/libc.so.6
#2 in row_mysql_handle_errors at row0mysql.cc:688
#3 in row_insert_for_mysqlat row0mysql.cc:1379
#4 in ha_innobase::write_row at ha_innodb.cc:7296
#5 in handler::ha_write_row at handler.cc:7659
#6 in write_record at sql_insert.cc:1947
#7 in mysql_insert at sql_insert.cc:1085
#8 in mysql_execute_command at sql_parse.cc:3884
#9 in mysql_parse at sql_parse.cc:6918
#10 in dispatch_command at sql_parse.cc:1434
#11 in do_command at sql_parse.cc:1051
#12 in do_handle_one_connection at sql_connect.cc:1532
#13 in handle_one_connection at sql_connect.cc:1443
#14 in start_thread () from /usr/lib64/libpthread.so.0
#15 in clone () from /usr/lib64/libc.so.6

How To Repeat:
------------------

drop table if exists `t1`;
create table `t1`(`a` int,`c` blob,`d` blob,`e` blob,`f` blob,primary key (`a`)) engine=innodb;
insert into `t1` values (1,'a', repeat('a',786),repeat('a',826), repeat('a',42));
insert into `t1` values (2,'a', repeat('a',488),repeat('a',1005),repeat('a',489));
insert into `t1` values (3,repeat('a',953), repeat('a',990),repeat('a',614), repeat('a',1000));
insert into `t1` values (4,repeat('a',661), repeat('a',236),repeat('a',911), repeat('a',67));
insert into `t1` values (5,repeat('a',1000),repeat('a',423),repeat('a',827), repeat('a',759));
set session innodb_fake_changes = 1 ;
insert into `t1` values (6,repeat('a',1000),repeat('a',423),repeat('a',827), repeat('a',759));

sbester (sbester) wrote :

With different inserts you'd also see this:
ERROR 1180 (HY000): Got error 131 during COMMIT

Download full text (5.6 KiB)

Thank you for the bug report. This is easy to confirm with previous version, 5.6.21-71.0 as well:

[openxs@chief p5.6]$ bin/mysql -uroot test
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 5.6.21-70.0 MySQL Community Server (GPL)

Copyright (c) 2009-2014 Percona LLC and/or its affiliates
Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> drop table if exists `t1`;
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql> create table `t1`(`a` int,`c` blob,`d` blob,`e` blob,`f` blob,primary key (`a`)) engine=innodb;
Query OK, 0 rows affected (0.65 sec)

mysql> insert into `t1` values (1,'a', repeat('a',786),repeat('a',826), repeat('a',42));
Query OK, 1 row affected (0.06 sec)

mysql> insert into `t1` values (2,'a', repeat('a',488),repeat('a',1005),repeat('a',489));
Query OK, 1 row affected (0.04 sec)

mysql> insert into `t1` values (3,repeat('a',953), repeat('a',990),repeat('a',614), repeat('a',1000));
Query OK, 1 row affected (0.08 sec)

mysql> insert into `t1` values (4,repeat('a',661), repeat('a',236),repeat('a',911), repeat('a',67));
Query OK, 1 row affected (0.09 sec)

mysql> insert into `t1` values (5,repeat('a',1000),repeat('a',423),repeat('a',827), repeat('a',759));
Query OK, 1 row affected (0.04 sec)

mysql> set session innodb_fake_changes = 1 ;
Query OK, 0 rows affected (0.00 sec)

mysql> insert into `t1` values (6,repeat('a',1000),repeat('a',423),repeat('a',827), repeat('a',759));
ERROR 2013 (HY000): Lost connection to MySQL server during query
mysql> 150114 09:02:06 mysqld_safe Number of processes running now: 0
150114 09:02:06 mysqld_safe mysqld restarted

mysql> exit
Bye
[openxs@chief p5.6]$ tail -100 data/chief.err
2015-01-14 09:01:38 2152 [Note] /home/openxs/dbs/p5.6/bin/mysqld: ready for connections.
Version: '5.6.21-70.0' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Server (GPL)
InnoDB: unknown error code 1000
2015-01-14 09:02:06 7fe6350aa700 InnoDB: Assertion failure in thread 140626709096192 in file row0mysql.cc line 688
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
07:02:06 UTC - mysqld got signal 6 ;
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.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have a...

Read more...

tags: added: fake-changes xtradb
sbester (sbester) wrote :

so now that the crash is published on https://www.percona.com/blog/2015/08/11/mysql-qa-episode-12-server-crashing-now-customers-users-experiencing-crash/ i suppose a fix should come sooner rather than later ;-)

Krunal Bauskar (krunal-bauskar) wrote :

commit 18dc2fbb910604ae826c3585f40a2994e24b88c4
Author: Krunal Bauskar <email address hidden>
Date: Tue Sep 8 10:54:23 2015 +0530

    - bug#1410410: innodb_fake_changes cause unknown error code 1000

      innodb_fake_changes allows user to dry run the workload.
      Dry run will execute the query part but will not make any modifications
      to DB there-by helping in warmup the cache. This feature eventually helps
      newly added slave to catch-up with replication faster.

      To faciliate this, search mode in-case of pessimistic insert is modified
      from BTR_MODIFY_TREE to BTR_SEARCH_TREE (newly added for this purpose).
      This mode switch takes S-latch instead of X-latch as S-latch is less
      restrictive and so is acceptable for dry-run workload requirement.

      Same search mode was used for insert too but without special handling
      in insert part and so even though pessimistic mode was invoked it caused
      optimistic insert to execute
        if (mode != BTR_MODIFY_TREE) {
                optimistic
        } else {
                pessimistic
        }

      with mode = BTR_SEARCH_TREE it defaulted to optimistic.

      We made the code consistent with previous revision to ensure that
      search_mode and mode (used for insert) are segregated to avoid re-use.

Pull-Request: #147

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PS-1601

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers