Hello Shahriyar,

I've downgraded the xtrabackup package to 32bit and I'm able to reproduce the issue right away. 

It fails with the following error:

160831 11:25:58 >> log scanned up to (1467219360314)
2016-08-31 11:25:58 0xea017b40  InnoDB: Assertion failure in thread 3925965632 in file os0file.cc line 1684
InnoDB: Failing assertion: offset > 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.7/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
15:25:58 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.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.

Thread pointer: 0x0
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
/usr/bin/xtrabackup(my_print_stacktrace+0x28)[0x88693c8]
/usr/bin/xtrabackup(handle_fatal_signal+0x224)[0x86735b4]
linux-gate.so.1(__kernel_sigreturn+0x0)[0xeea20410]
linux-gate.so.1(__kernel_vsyscall+0x10)[0xeea20440]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(gsignal+0x47)[0xee5e1367]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(abort+0x143)[0xee5e2a23]
/usr/bin/xtrabackup[0x8311d99]
/usr/bin/xtrabackup[0x8606583]
/usr/bin/xtrabackup[0x8606cdb]
/usr/bin/xtrabackup[0x8606e90]
/usr/bin/xtrabackup[0x8607036]
/usr/bin/xtrabackup(_Z17os_file_read_funcR9IORequestiPvym+0x21)[0x8607531]
/usr/bin/xtrabackup(_Z15xb_fil_cur_readP12xb_fil_cur_t+0x286)[0x83486d6]
/usr/bin/xtrabackup[0x8336fe2]
/usr/bin/xtrabackup[0x833e6c8]
/lib/i386-linux-gnu/i686/cmov/libpthread.so.0(+0x6efb)[0xee9efefb]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(clone+0x5e)[0xee69eede]

Please report a bug at https://bugs.launchpad.net/percona-xtrabackup

The config of the mysqld is: 

# The MySQL server
[mysqld]
port        = 3306
socket      = /tmp/mysql.sock
skip-external-locking
default-storage-engine = myisam
key_buffer_size = 256M
max_allowed_packet = 32M
table_open_cache = 1024
open_files_limit = 10000
sort_buffer_size = 1M
read_buffer_size = 1M
read_rnd_buffer_size = 4M
myisam_sort_buffer_size = 64M
thread_stack = 262144
thread_cache_size = 8
query_cache_type = 1
query_cache_size= 256M
query_cache_limit= 2M
table_definition_cache = 2048
temp-pool = 0
max_heap_table_size = 134217728
tmp_table_size = 134217728
max_connections = 300
max_user_connections = 40
max_connect_errors = 100
performance_schema = off
slow_query_log = 1
long-query-time = 0.1
log_error_verbosity=3
secure_file_priv=NULL
sql_mode=NO_ENGINE_SUBSTITUTION
server-id   = 1
tmpdir      = /usr/local/lib/mysql5/tmp/
innodb_file_per_table = 1
userstat = 1
ft_min_word_len = 3
event_scheduler=OFF

We invoke the xtrabackup with the following options:
/usr/bin/xtrabackup --defaults-file=/usr/local/lib/mysql5.innobackupex/xtrabackup.cnf --stream=xbstream --backup --compress --compress-threads=1 --tables-file=/usr/local/lib/mysql5.innobackupex/tables.txt --no-lock

Please advise if I can help with any additional debug info.

Regards 

Iavor