Comment 0 for bug 839306

Revision history for this message
Mr. Bob (mrbob0473) wrote : Failing assertion: addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA

When runing the prepare command line, it will ran into a "Failing assertion".
$ ~/local/bin/xtrabackup_55 --prepare --target-dir=`pwd` --tmpdir=/tmp
/export/home/mysql/local/bin/xtrabackup_55 Ver 1.6 Rev undefined for 5.5.9 Linux (x86_64)
xtrabackup: cd to /data/backup/full/2011-09-01_06-27-55
xtrabackup: This target seems to be not prepared yet.
110901 22:58:41 InnoDB: Operating system error number 2 in a file operation.
InnoDB: The error means the system cannot find the path specified.
xtrabackup: Warning: cannot open ./xtrabackup_logfile. will try to find.
  xtrabackup: 'ib_logfile0' seems to be 'xtrabackup_logfile'. will retry.
xtrabackup: xtrabackup_logfile detected: size=6089359360, start_lsn=(1336207695220)
xtrabackup: Temporary instance for recovery is set as followings.
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 6089359360
110901 22:58:42 InnoDB: Using Linux native AIO
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
110901 22:58:42 InnoDB: The InnoDB memory heap is disabled
110901 22:58:42 InnoDB: Mutexes and rw_locks use GCC atomic builtins
110901 22:58:42 InnoDB: Compressed tables use zlib 1.2.3
110901 22:58:42 InnoDB: Using Linux native AIO
110901 22:58:42 InnoDB: Warning: innodb_file_io_threads is deprecated. Please use innodb_read_io_threads and innodb_write_io_threads instead
110901 22:58:42 InnoDB: Initializing buffer pool, size = 100.0M
110901 22:58:42 InnoDB: Completed initialization of buffer pool
110901 22:58:42 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 1336207695220
110901 22:58:42 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Doing recovery: scanned up to log sequence number 1336212937728 (0 %)
InnoDB: Doing recovery: scanned up to log sequence number 1336218180608 (0 %)
InnoDB: Doing recovery: scanned up to log sequence number 1336223423488 (0 %)
InnoDB: Doing recovery: scanned up to log sequence number 1336228666368 (0 %)
InnoDB: Doing recovery: scanned up to log sequence number 1336233909248 (0 %)
InnoDB: Doing recovery: scanned up to log sequence number 1336234756658 (0 %)
110901 22:58:52 InnoDB: Assertion failure in thread 47344695498128 in file /home/buildbot/slaves/percona-server-51-12/TGZ_CentOS_5_x86_64/work/xtrabackup-1.6/Percona-Server-5.5/storage/innobase/include/fut0lst.ic line 83
InnoDB: Failing assertion: addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
Aborted