The tests stdio-common/test-vfprintf and stdio-common/bug22 fail if the memory
available is limited (e.g. 200MB).  This can be reproduced on a system with
more memory by:

ulimit -d 200000
ulimit -m 200000
ulimit -v 200000

before running the tests (tested x86_64).

In the test-vfprintf case, test-vfprintf.out contains

file size incorrect for locale C: 99999 instead of 100004
file size incorrect for locale de_DE.ISO-8859-1: 99999 instead of 100004
file size incorrect for locale de_DE.UTF-8: 99999 instead of 100004
file size incorrect for locale ja_JP.EUC-JP: 99999 instead of 100004

and for bug22, bug22.out contains

ret = -1
ret = -1
ret = -1
ret = -1

In general the testsuite tries to limit failures to those showing actual
problems with glibc functionality that would be expected to work on the given
architecture - for example, by testing for functions that may fail with ENOSYS
on some systems and exiting tests early and successfully in those cases. 
(Ideally such tests would have an UNRESOLVED or UNSUPPORTED result different
from PASS and FAIL, but the testsuite doesn't support that.)  I think the same
should apply to allocation failures in these tests that involve stdio code
allocating large amounts of memory: the tests should exit successfully in that
case.