MySQL Bugs: #74605: Failing assertion: node_addr.page != FIL

Bug #74605	Failing assertion: node_addr.page != FIL_NULL in file btr0btr.cc line 1081
Submitted:	28 Oct 2014 13:50	Modified:	30 Oct 2014 16:24
Reporter:	Ramesh Sivaraman	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: InnoDB storage engine	Severity:	S3 (Non-critical)
Version:	5.6.20-debug, 5.6.22, 5.7.6	OS:	Linux (CentOS 7)
Assigned to:		CPU Architecture:	Any

Description:
2014-10-28 13:41:00 7f9da72da700  InnoDB: Assertion failure in thread 140315091379968 in file btr0btr.cc line 1081
InnoDB: Failing assertion: node_addr.page != FIL_NULL
nnoDB: 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.
13:41:00 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 already crashed, 
something is definitely wrong and this may fail.

key_buffer_size=8388608
read_buffer_size=131072
max_used_connections=1
max_threads=151
thread_count=1
connection_count=1
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68249 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x7f9d13b24000
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 7f9da72d9e20 thread_stack 0x40000
/ssd/ramesh/mysql-server/mysql-5.6.20-linux-x86_64-debug/bin/mysqld(my_print_stacktrace+0x35)[0xa902dc]
/ssd/ramesh/mysql-server/mysql-5.6.20-linux-x86_64-debug/bin/mysqld(handle_fatal_signal+0x3f3)[0x7234a3]
/lib64/libpthread.so.0(+0xf130)[0x7f9da6ce4130]
/lib64/libc.so.6(gsignal+0x39)[0x7f9da5aed5c9]
/lib64/libc.so.6(abort+0x148)[0x7f9da5aeecd8]
/ssd/ramesh/mysql-server/mysql-5.6.20-linux-x86_64-debug/bin/mysqld[0xce5b36]
[..]
/ssd/ramesh/mysql-server/mysql-5.6.20-linux-x86_64-debug/bin/mysqld[0xb557b7]
/ssd/ramesh/mysql-server/mysql-5.6.20-linux-x86_64-debug/bin/mysqld(_ZN7handler15ha_delete_tableEPKc+0x6a)[0x63c344]
/ssd/ramesh/mysql-server/mysql-5.6.20-linux-x86_64-debug/bin/mysqld(_ZN12ha_partition13del_ren_tableEPKcS1_+0x2bc)[0xe05cb6]
/ssd/ramesh/mysql-server/mysql-5.6.20-linux-x86_64-debug/bin/mysqld(_ZN12ha_partition12delete_tableEPKc+0x58)[0xe01b4c]
/ssd/ramesh/mysql-server/mysql-5.6.20-linux-x86_64-debug/bin/mysqld(_ZN7handler15ha_delete_tableEPKc+0x6a)[0x63c344]
/ssd/ramesh/mysql-server/mysql-5.6.20-linux-x86_64-debug/bin/mysqld(_Z15ha_delete_tableP3THDP10handlertonPKcS4_S4_b+0x156)[0x6373fb]
/ssd/ramesh/mysql-server/mysql-5.6.20-linux-x86_64-debug/bin/mysqld(_Z23mysql_rm_table_no_locksP3THDP10TABLE_LISTbbbb+0xb14)[0x834167]
/ssd/ramesh/mysql-server/mysql-5.6.20-linux-x86_64-debug/bin/mysqld(_Z14mysql_rm_tableP3THDP10TABLE_LISTcc+0x3c7)[0x8335bd]
/ssd/ramesh/mysql-server/mysql-5.6.20-linux-x86_64-debug/bin/mysqld(_Z21mysql_execute_commandP3THD+0x3730)[0x7d2058]
/ssd/ramesh/mysql-server/mysql-5.6.20-linux-x86_64-debug/bin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x485)[0x7d8fa4]
/ssd/ramesh/mysql-server/mysql-5.6.20-linux-x86_64-debug/bin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0xcbe)[0x7cc557]
/ssd/ramesh/mysql-server/mysql-5.6.20-linux-x86_64-debug/bin/mysqld(_Z10do_commandP3THD+0x33e)[0x7cb646]
/ssd/ramesh/mysql-server/mysql-5.6.20-linux-x86_64-debug/bin/mysqld(_Z24do_handle_one_connectionP3THD+0x1b6)[0x793a61]
/ssd/ramesh/mysql-server/mysql-5.6.20-linux-x86_64-debug/bin/mysqld(handle_one_connection+0x33)[0x79354a]
/ssd/ramesh/mysql-server/mysql-5.6.20-linux-x86_64-debug/bin/mysqld(pfs_spawn_thread+0x159)[0xad4b5c]
/lib64/libpthread.so.0(+0x7df3)[0x7f9da6cdcdf3]
/lib64/libc.so.6(clone+0x6d)[0x7f9da5bae01d]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7f9d09c1f010): DROP TABLE IF EXISTS t1
Connection ID (thread ID): 1
Status: NOT_KILLED

How to repeat:
DROP DATABASE test;CREATE DATABASE test;USE test;
SET GLOBAL innodb_change_buffering_debug=1;
CREATE TABLE t1(c1 INT)PARTITION BY HASH (c1) PARTITIONS 15;
SET @start_global_value=@@global.innodb_spin_wait_delay;
SET @@global.innodb_limit_optimistic_insert_debug=@start_global_value;
create table tt(a int,b int,primary key(a,b));
set global innodb_limit_optimistic_insert_debug=1;
DROP TABLE IF EXISTS t1;

Hello Ramesh Sivaraman,

Thank you for the report and test case.
Confirmed with 5.6.22 that only debug builds affected.

Thanks,
Umesh

test results

Attachment: 74605_5_6_22.txt (text/plain), 10.97 KiB.

// 5.7.6 debug build also affected

test results

Attachment: 74605_5_7_6.txt (text/plain), 10.75 KiB.

Thanks for the report.

The problem is in the debug variable innodb_limit_optimistic_insert_debug. If you set it to the value 1, it will cause an infinite B-tree split.

With the supplied test case, the infinite B-tree split occurs in the InnoDB change buffer, because innodb_change_buffering_debug=1 is trying to use the change buffer as much as possible.

The fix is simple: with the values 0 and 1 of innodb_limit_optimistic_insert_debug, we must disable the special instrumentation.

Posted by developer:
 
Fixed as of the upcoming 5.5.41, 5.6.22, 5.7.6  releases, and here's the changelog entry:

In debug builds, setting the "innodb_limit_optimistic_insert_debug" debug
configuration option to 1 would cause an infinite B-tree page split.

Thank you for the bug report.

Bug#74577 was marked as a duplicate.

$ bzr log -r 4734
------------------------------------------------------------
revno: 4734
committer: Marko Makela <marko.makela@oracle.com>
branch nick: mysql-5.5
timestamp: Thu 2014-10-30 08:53:46 +0200
message:
  Bug#19904003 INNODB_LIMIT_OPTIMISTIC_INSERT_DEBUG=1 CAUSES INFINITE PAGE SPLIT
  
  The debug configuration parameter innodb_optimistic_insert_debug
  which was introduced for testing corner cases in B-tree handling
  had a bug in it. The value 1 would trigger an infinite sequence
  of page splits.
  
  Fix: When the value 1 is specified, disable this debug feature.
  Approved by Yasufumi Kinoshita

See bug 75784