Bug 386

I don't think there is any case left where ENOMEM is returned.  If yes, provide
a test case.

Hello, 

If you set ulimit -s 512000 (thread_stack) on a 32bit system with >2GB RAM it is
possible to get pthread_create to return ENOMEM.  Strangely, ulimit -s unlimited
or ulimit -s 8192 does not produce this ENOMEM result.

Does pthread_create allocate a whole thread_stack size buffer for each thread if
a ulimit -s is defined?

See: http://bugs.mysql.com/bug.php?id=27487
OS error code  12:  Cannot allocate memory

InnoDB: Error: pthread_create returned 12
070329 14:54:41  mysqld ended

This behavior has been experienced on:

RHEL3 (2.4.21-37.ELsmp) 
and
SuSE 10.1 (2.6.16.13-4-default)
glibc-2.4-31

Oddly enough, it is more convenient to return the actual error code rather than 
generic EAGAIN  (which would leave programmers blind ...). I would rather say 
to revise POSIX standard.... 

You haven't shown where in the current libc code there is a problem.  Citing
ancient libcs has no value at all.  Here we are concern exclusively with
current, upstream code.

Hi,

Even pthread_create() returns the errno, but it doestnot sets the errno EAGAIN, 
instead it retains the ENOMEM. I have verified in glibc-2.7.

Thats why the attached testcase results in..

$gcc -o test test.c -lpthread

$./test
pthread_create : Cannot allocate memory -> 12
Created 405 threads
pthread_create : Cannot allocate memory -> 12
..........
..........

errno value set to 12 (ENOMEM)
but needs to be EAGAIN.


Ths attached patch fixes this issue.

$./test
pthread_create : Resource temporarily unavailable -> 11
Created 405 threads
pthread_create : Resource temporarily unavailable -> 11
................
................

Thanks,
Halesh

Created attachment 2813 [details]
test case

Test Case

Created attachment 2814 [details]
patch to fix the issue

Don't ever report problem unless you can reproduce them with the latest glibc
code from cvs.  I've said this before, even in this bug, why the f*ck don't you
read that first?  There is no problem I can see in the current code.

I was just able to reproduce this.  Using strace I discovered that ENOMEM was coming from the mprotect() call that sets up the guard page.  And indeed this seems to be a case that isn't converting ENOMEM -> EAGAIN.

http://sourceware.org/git/?p=glibc.git;a=blob;f=nptl/allocatestack.c;h=ba251b91626cd1463a19f9db3fbed85eec585897;hb=be9c5e8b2014bdbf724f206bb25249c67115db49#l636

mprotect() returns ENOMEM if you've hit the maximum number of mappings for a process (which on Linux is currently is 65050).

(In reply to comment #9)
> I was just able to reproduce this.  Using strace I discovered that ENOMEM was
> coming from the mprotect() call that sets up the guard page.  And indeed this
> seems to be a case that isn't converting ENOMEM -> EAGAIN.

That's a good catch.  I changed the code.