Innobackupex --apply-log fails

I have been trying weeks to build a MySQL slave and I’m completely and utterly frustrated with this. I thought I had this beat last night, but once again it fails. To create my snapshot of my MASTER MySQL server, I ran the following command:

innobackupex --defaults-file=/opt/pkgs/mysql/my.cnf --rsync --safe-slave-backup --compress --compress-threads=4 --user=USER --password=PWD /apps/Dbbackup/jamen/

This completed beautifully and in only a couple of hours will not much of a drain on the server (which was imperative). However, when I try to run the apply-log, I get an error. This is the command I am trying to run:

innobackupex --user=USER --password=PWD --apply-log /apps/Dbbackup/jamen/2013-07-17_21-51-42

And this is what I get:

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=2981888, start_lsn=(201164172631)
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 = 2981888
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 = 2981888
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
130718 7:37:33 InnoDB: The InnoDB memory heap is disabled
130718 7:37:33 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130718 7:37:33 InnoDB: Compressed tables use zlib 1.2.3
130718 7:37:33 InnoDB: Initializing buffer pool, size = 100.0M
130718 7:37:33 InnoDB: Completed initialization of buffer pool
130718 7:37:33 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 201164172631
130718 7:37:33 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 201165485500 (49 %)
130718 7:37:33 InnoDB: Assertion failure in thread 47555864079120 in file fsp0fsp.c line 2949
InnoDB: Failing assertion: space != 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: [url]http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html[/url]
InnoDB: about forcing recovery.
innobackupex: Error:
innobackupex: ibbackup failed at /usr/bin/innobackupex line 389.

Can you share more details? What is the MySQL and XtraBackup version? Any errors noted during backup?
Also the /apps/Dbbackup/jamen/2013-07-17_21-51-42 seems to be already tried to prepare/apply-log? ib_logfile0 was already present…
I think fsp0fsp.c line 2949 would indicate some corruption in InnoDB table space, which could be a result of previous unsuccessful prepare/recovery stage.