InnoDB: Failing assertion: mode == BUF_GET_POSSIBLY_FREED || !block->page.file_page_was_freed in file buf0buf.c line 2910

Bug #1100178 reported by Roel Van de Paar
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MySQL Server
Unknown
Unknown
Percona Server moved to https://jira.percona.com/projects/PS
Fix Released
High
Laurynas Biveinis
5.1
Fix Released
High
Laurynas Biveinis
5.5
Fix Released
High
Laurynas Biveinis
5.6
Fix Released
High
Laurynas Biveinis

Bug Description

130115 16:59:15 InnoDB: Assertion failure in thread 386742016 in file buf0buf.c line 2910
InnoDB: Failing assertion: mode == BUF_GET_POSSIBLY_FREED || !block->page.file_page_was_freed

Thread 24 (LWP 10333):
+bt
#0 0x0000003da180c60c in pthread_kill () from /lib64/libpthread.so.0
#1 0x00000000007dc4a8 in my_write_core (sig=6) at /ssd/bug1086680/Percona-Server-5.5.28-rel29.2/mysys/stacktrace.c:433
#2 0x00000000006b1b68 in handle_fatal_signal (sig=6) at /ssd/bug1086680/Percona-Server-5.5.28-rel29.2/sql/signal_handler.cc:249
#3 <signal handler called>
#4 0x0000003da1435935 in raise () from /lib64/libc.so.6
#5 0x0000003da14370e8 in abort () from /lib64/libc.so.6
#6 0x00000000008e3014 in buf_page_get_gen (space=space@entry=621, zip_size=zip_size@entry=8192, offset=offset@entry=146, rw_latch=rw_latch@entry=3, guess=guess@entry=0x0, mode=mode@entry=14, file=file@entry=0xb8e6d0 "/ssd/bug1086680/Percona-Server-5.5.28-rel29.2/storage/innobase/lock/lock0lock.c", line=line@entry=4664, mtr=mtr@entry=0x170d2800) at /ssd/bug1086680/Percona-Server-5.5.28-rel29.2/storage/innobase/buf/buf0buf.c:2909
#7 0x0000000000973b8a in lock_print_info_all_transactions (file=file@entry=0x5d0e6f0) at /ssd/bug1086680/Percona-Server-5.5.28-rel29.2/storage/innobase/lock/lock0lock.c:4663
#8 0x00000000008708c2 in srv_printf_innodb_monitor (file=0x5d0e6f0, nowait=nowait@entry=1, trx_start=trx_start@entry=0x0, trx_end=trx_end@entry=0x0) at /ssd/bug1086680/Percona-Server-5.5.28-rel29.2/storage/innobase/srv/srv0srv.c:2263
#9 0x0000000000871592 in srv_monitor_thread (arg=<optimized out>) at /ssd/bug1086680/Percona-Server-5.5.28-rel29.2/storage/innobase/srv/srv0srv.c:2580
#10 0x0000003da1807d14 in start_thread () from /lib64/libpthread.so.0
#11 0x0000003da14f168d in clone () from /lib64/libc.so.6

Tags: innodb qa

Related branches

Revision history for this message
Roel Van de Paar (roel11) wrote :
Revision history for this message
Roel Van de Paar (roel11) wrote :
Revision history for this message
Roel Van de Paar (roel11) wrote :

Valgrind in buf_page_get_gen in bug 1086680

Revision history for this message
Laurynas Biveinis (laurynas-biveinis) wrote :

lock_print_info_all_transactions attempts to load a buffer page for a possible eventual detailed lock dump:

   lock_mutex_exit_kernel();

   mtr_start(&mtr);

   buf_page_get_with_no_latch(space, zip_size,
         page_no, &mtr);

   mtr_commit(&mtr);

   load_page_first = FALSE;

   lock_mutex_enter_kernel();

First of all, this does not seem to be necessary at all when XtraDB-specific innodb_show_verbose_locks is 0 (which it is in this case).
Second, the buffer page read happens with no locks held, thus the read must handle everything, including a disappearing page, which is the cause of this crash. The latter seems to apply to InnoDB too.

Revision history for this message
Laurynas Biveinis (laurynas-biveinis) wrote :

The redundant page reads for innodb_show_verbose_locks=0 is bug 1100643 now.

Revision history for this message
Laurynas Biveinis (laurynas-biveinis) wrote :

Confirmed for 5.1 by code analysis.

Revision history for this message
Laurynas Biveinis (laurynas-biveinis) wrote :

The upstream fixed other instances this assertion might come up by the following commit in 5.5.

$ bzr log -r 3400
------------------------------------------------------------
revno: 3400
committer: Marko Mäkelä <email address hidden>
branch nick: mysql-5.5
timestamp: Tue 2011-05-24 23:08:22 +0300
message:
  Bug#12584374 LOCK_VALIDATE TRIPS ASSERTION !BLOCK->PAGE.FILE_PAGE_WAS_FREE

  Fix a deadlock in the initial patch. lock_validate() must not hold the
  lock system mutex while s-latching a block, because some functions,
  such as lock_rec_convert_impl_to_expl(), may be already holding an x-latch
  on the block that lock_validate() is interested in while attempting to
  acquire the lock system mutex.

  This deadlock was not caught by UNIV_SYNC_DEBUG because of
  buf_block_dbg_add_level(block, SYNC_NO_ORDER_CHECK).

Revision history for this message
Laurynas Biveinis (laurynas-biveinis) wrote :

I cannot find any attempts to fix this for 5.1 in the upstream.

Revision history for this message
Roel Van de Paar (roel11) wrote :

Roel has testcase (same one as for bug bug1086680 / bug 1083058).

tags: added: innodb
Revision history for this message
Shahriyar Rzayev (rzayev-sehriyar) wrote :

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

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

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.