Please check your user limits!
If one or several tests of the test suite fail, it is very likely that your user limits for stack size and/or memory are too small.
sh/bash/ksh users: please do a
to get your actual limits. The output should look like:
The most important entries are data size, stack size, max memory size, and virtual memory. Those should be either unlimited or as big as your total RAM.
To set, e.g. the stack size to the maximum allowed size on your system (the so called hard limit), do:
ulimit -s hard
csh/tcsh users: please do limit instead of ulimit and check the output.
Again, like given above, the limits should be at least as high as your memory available. The syntax for changing the limits to unlimited using csh/tcsh is:
limit stacksize hard
If you are using a queuing system:
Note that if you are submitting jobs to a queue, the user limits might be different from what you get when you log in on the machines! To check your limits, you have to add ulimit or limit in the script that is sent to the queue:
send it to the queue and check the file mylimits.out to find out which limits are set.
The parallel binaries are being started by the mpirun command which often uses ssh to start a process on a remote node. The limits for the stack size can not be set by the user in such a case, so everything in $HOME/.profile, $HOME/.bashrc, etc. will not help to get rid of the problem.
To check the limits on a remote node, try (sh/bash/ksh syntax):
ssh <hostname> ulimit -a
If the ssh command gives a lower stack size than unlimited or a large number, you have to change the file
on all nodes where the parallel binaries might run, and add there the line (example for 4GB limit)
Redo ssh <hostname>ulimit -a and you should get 4GB stack size limit, as it is set in limits.conf now.