I recently encountered this same bug using percona-xtrabackup 2.2.9 to prepare

the crash info is as follow

2015-05-12 19:03:08 7fd9d8258720  InnoDB: Assertion failure in thread 140573610968864 in file pars0pars.cc line 865
InnoDB: Failing assertion: sym_node->table != NULL
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.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
11:03:08 UTC - xtrabackup got signal 6 ;
This could be because you hit a bug or data is corrupted.
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.

Thread pointer: 0x176aeb0
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 = 0 thread_stack 0x10000
xtrabackup(my_print_stacktrace+0x35) [0x9f5331]
xtrabackup(handle_fatal_signal+0x2bb) [0x7f801b]
/lib64/libpthread.so.0() [0x3530c0f500]
/lib64/libc.so.6(gsignal+0x35) [0x35f40328a5]
/lib64/libc.so.6(abort+0x175) [0x35f4034085]
xtrabackup() [0x76bfb0]
xtrabackup(pars_update_statement(upd_node_t*, sym_node_t*, void*)+0x30) [0x76c8d8]
xtrabackup(yyparse()+0xcb1) [0xa5ef27]
xtrabackup(pars_sql(pars_info_t*, char const*)+0xaf) [0x76e06d]
xtrabackup(que_eval_sql(pars_info_t*, char const*, unsigned long, trx_t*)+0x85) [0x78eeb2]
xtrabackup(row_drop_table_for_mysql(char const*, trx_t*, bool, bool)+0xa98) [0x720a0c]
xtrabackup(row_mysql_drop_temp_tables()+0x24c) [0x721503]
xtrabackup(recv_recovery_rollback_active()+0x2c) [0x753ebe]
xtrabackup(innobase_start_or_create_for_mysql()+0x17aa) [0x7293c4]
xtrabackup() [0x607a00]
xtrabackup() [0x610204]
xtrabackup(main+0x8b8) [0x611674]
/lib64/libc.so.6(__libc_start_main+0xfd) [0x35f401ecdd]
xtrabackup() [0x604369]


And this the repeat process is as follow:
1. a 5.5 server
2. establish a session to this sever, execute create temporary table tmp_crash(id int) engine=InnoDB, and hold this session so that tmp table don't get droped
3. do a backup against this server using xtrabackup 2.2
4. after backup finished, prepare using xtrabackup 2.2
and will see this crash.


After some dig into the code, it can be confirmed a incompatibility problem between MySQL 5.5(include PS55) and MySQL 5.6.

In Xtrabackup 2.2, the xtrabackup binary is compile against MySQL 5.6.22, and just one binary file, not like before there were multi version xtrabackup binary, compiled against MySQL 5.5/5.1 etc.
In  MySQL 5.6 InnoDB, there are 2 more internal tables(SYS_TABLESPACES,SYS_DATAFILES) than 5.5, and that's the problem. If there are tmp table in backup file, where prepared, a InnoDB engine
started, and at start it will try to drop tmp table, which will lead to this crash. Cause in 5.5 there are no SYS_TABLESPACES and SYS_DATAFILES sys tables, xtrabackup try to delete tmp table record
from these 2 tables, then crashed.


I tried to prepare the same backup file use xtrabackup 2.1.9, everything goes well, and the log is as below;

InnoDB: We removed now the InnoDB internal data dictionary entry
InnoDB: of table "tmp"."#sqlf623_4201_0".
InnoDB: We removed now the InnoDB internal data dictionary entry
InnoDB: of table "tmp"."#sqlf623_4201_1".
InnoDB: We removed now the InnoDB internal data dictionary entry
InnoDB: of table "tmp"."#sqlf623_668f_0".
InnoDB: We removed now the InnoDB internal data dictionary entry
InnoDB: of table "tmp"."#sqlf623_668f_1".
150512 19:05:32  InnoDB: Waiting for the background threads to start
150512 19:05:33 Percona XtraDB (http://www.percona.com) 5.5.35-33.0 started; log sequence number 1131785184


And the fix is simple,  during prepare, we first check if there are SYS_TABLESPACES or SYS_DATAFILES  sys tables in row_drop_table_for_mysql() , if not, don't delete from this two tables.