xtrabackup's --parallel option asserts / crashes with a value of -1

To repeat via dbqp:
 ./dbqp.py --default-server-type=mysql --basedir=/mysql-5.5 --xtrabackup-path=/percona-xtrabackup/mysql-5.5/storage/innobase/xtrabackup/xtrabackup_innodb55 --innobackupex-path=/percona-xtrabackup/innobackupex --suite=xtrabackup_basic bug884737_test

--parallel=0 works a-ok.
When it is 0, the option seems to be dropped from the xtrabackup call.
We might wish to document this, even though nobody should ever *really* try this (except devious QA guys...) : )

Affected with --parallel=1000000000000 option, with xtrabackup 2.3.2:

[root@node1 mysql]# innobackupex --defaults-file=/etc/my.cnf --user=root --password=12345 --port=3306 --socket=/var/lib/mysql/mysql.sock --parallel=1000000000000 /home/MySQL-AutoXtraBackup/backup_dir/full/
Warning: option 'parallel': signed value 1000000000000 adjusted to 2147483647
151026 11:13:36 innobackupex: Starting the backup operation

IMPORTANT: Please check that the backup run completes successfully.
           At the end of a successful backup run innobackupex
           prints "completed OK!".

151026 11:13:36 version_check Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup;port=3306;mysql_socket=/var/lib/mysql/mysql.sock' as 'root' (using password: YES).
151026 11:13:36 version_check Connected to MySQL server
151026 11:13:36 version_check Executing a version check against the server...
151026 11:13:36 version_check Done.
151026 11:13:36 Connecting to MySQL server host: localhost, user: root, password: set, port: 3306, socket: /var/lib/mysql/mysql.sock
Using server version 5.6.26-74.0-log
innobackupex version 2.3.2 based on MySQL server 5.6.24 Linux (x86_64) (revision id: 306a2e0)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /var/lib/mysql
xtrabackup: open files limit requested 0, set to 1024
xtrabackup: using the following InnoDB configuration:
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:12M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 2
xtrabackup: innodb_log_file_size = 50331648
151026 11:13:36 >> log scanned up to (1223269683)
xtrabackup: Generating a list of tablespaces
xtrabackup: Starting 2147483647 threads for parallel data files transfer
2015-10-26 11:13:37 7f938241e740 InnoDB: Assertion failure in thread 140271522277184 in file ut0mem.cc line 105
InnoDB: Failing assertion: ret || !assert_on_error
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.
07:13:37 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: 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
innobackupex(my_print_stacktrace+0x2e) [0x927d2e]
innobackupex(handle_fatal_signal+0x262) [0x7214b2]
/lib64/libpthread.so.0(+0xf130) [0x7f9381ffe130]
/lib64/libc.so.6(gsignal+0x37) [0x7f938076b5d7]
/lib64/libc.so.6(abort+0x148) [0x7f938076ccc8]
innobackupex(ut_malloc_low(unsigned lo...

Well, this error is simply out of memory. That is how it handled by InnoDB.

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