Bug 461481

Description of problem:

When each thread of a multi-threaded process calls valloc()
individually, valloc() sometimes fails with ENOMEM even if the virtual
memory of the process is available enough.

Version-Release number of selected component:

 Red Hat Enterprise Linux Version Number: 5
 Release Number: 2
 Architecture: ia64
 Kernel Version: 2.6.18-92.el5
 Related Package Version: glibc-2.5-24
 Related Middleware / Application: None

How reproducible:
Always.

Step to Reproduce:
Execute our reproducer as follows.

1) Extract our tar ball.
$ tar zxf mvalloc-race.tar.gz

2) Compile the reproducer.
$ cd mvalloc
$ make

3) Execute a reproducer.
$ ./mvalloc-race-v7

Actual Results:
valloc() fails with ENOMEM even if the virtual memory is
available enough.

The output of the reproducer is as follows.

localhost% ./mvalloc-race-v7
valloc(4063232) failed, err:12
zsh: 31196 abort (core dumped)  ./mvalloc-race-v7

Hardware configuration:

 Model: PRIMEQUEST 580
 CPU Info: Itanium 2(1.6GHz) x4
 Memory Info: 4GB
 Hardware Component Information: None
 Configuration Info: None
 Guest Configuration Info: None


It was tried memalign() instead of valloc() in the reproducer because
specification difference between valloc() and memalign() is not so much, 
but this problem does -not- occurred.

The implementation difference between valloc() and memalign() is its
action when _int_memalign() returns NULL. I think this difference
causes this problem. The detail of the action is as follows.

The memalign() checks the return value of _int_memalign(). If
_int_memalign() returns NULL, memalign() tries to get memory from the
main_arena. However, valloc() does not check the return value of
_int_valloc() that is the return value of _int_memalign().
_int_valloc() calls _int_memalign() internally. I think this is the
reason why valloc() fails with ENOMEM, and why memalign() does not fail.