Incremental xtrabackup failure

[mtkopone]

Output:
--
$ ./xtrabackup-1.0 --defaults-file=/etc/mysql/my.cnf --backup --
incremental-lsn="0:368419190" --target-dir=/home/mysql/testing/
incremental
./xtrabackup-1.0 Ver beta-0.6 for 5.1.34 pc-linux-gnu (i686)
incremental backup from 0:368419190 is enabled.
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /var/lib/mysql
xtrabackup: Target instance is assumed as followings.
xtrabackup: innodb_data_home_dir = /var/lib/mysql
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = /var/lib/mysql
xtrabackup: innodb_log_files_in_group = 2
xtrabackup: innodb_log_file_size = 5242880
>> log scanned up to (0 368490227)

Copying /var/lib/mysql/ibdata1
     to /home/mysql/testing/incremental/ibdata1.delta
090520 13:57:28 InnoDB: Assertion failure in thread 3084293808 in
file xtrabackup.c line 1568
InnoDB: Failing assertion: page_offset >> 32 == 0
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.1/en/forcing-recovery.html
InnoDB: about forcing recovery.
Aborted

--

I've tried both a 0.6-binary compiled for 32-bit machines, and the 1.0-release branch compiled against 5.1.34 with the fix_innodb_for_backup51.patch. With both, I get the same error.

The lsn given on the commandline is correct. It also happens both with both the --incremental-lsn and --incremental-basedir -options.

It's a test setup, so I'm running VMWare 2.0.0,
With a virtual server running debian lenny:
Linux vm2 2.6.26-2-686 #1 SMP Thu Mar 26 01:08:11 UTC 2009 i686 GNU/Linux.
and the mysql I'm testing against is:
mysql Ver 14.14 Distrib 5.1.34, for debian-linux-gnu (i486) using readline 5.2

[Yasufumi Kinoshita (yasufumi-kinoshita)]

"InnoDB: Failing assertion: page_offset >> 32 == 0"
This may mean that the /var/lib/mysql/ibdata1 is over 70TB file...

If not, it may be bug of VM. Do you meet same phenomena on the real server?

[mtkopone (koponen)]

ibdata1 was only ~ 250 MB.

We already moved on from those 32-bit test servers, and haven't encountered this in our current 64-bit environment.

[Iain Arnell (iarnell)]

I've just run into the same problem with r79 on 32-bit equipment - not reproducible on 64-bit. Test database is tiny - ibdata1 is only 10Mb.

During compilation on 32-bit, warning is generated (also not on 64-bit):

xtrabackup.c: In function 'xtrabackup_copy_datafile':
xtrabackup.c:1593: warning: right shift count >= width of type

and the corresponding line 1593 indeed seems to be the failing assertion:

    ut_a(page_offset >> 32 == 0);

[Yasufumi Kinoshita (yasufumi-kinoshita)]

Fixed at
http://bazaar.launchpad.net/~percona-dev/percona-xtrabackup/trunk/revision/84

[Iain Arnell (iarnell)]

Sorry - I forgot to report back earlier. The fix in r84 does indeed fix this for me.

[Shahriyar Rzayev (rzayev-sehriyar)]

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