This is sources Bugzilla
Bugzilla Version 2.17.5
Bugzilla Bug 386
  pthread_create returns ENOMEM but should return EAGAIN Last modified: 2008-07-26 23:51
     Query page      Enter new bug
Bug#: 386   Hardware:   Reporter: Sebastien Decugis <sebastien.decugis@ext.bull.net>
Host: Target: Build:
Product:     Add CC:
Component:   Version:   CC:
Remove selected CCs
Status: RESOLVED   Priority:  
Resolution: WORKSFORME   Severity:  
Assigned To: Ulrich Drepper <drepper@redhat.com>   Target Milestone:  
Flags: Requestee:
  backport ()
  examined ()
  testsuite ()
Summary:
Keywords:

Attachment Description Type Created Actions
test.c test case text/plain 2008-07-03 13:53 Edit None
pthread_create.c.patch patch to fix the issue patch 2008-07-03 13:53 Edit | Diff
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 386 depends on: Show dependency tree
Show dependency graph
Bug 386 blocks:

Additional Comments:


Leave as RESOLVED WORKSFORME
Reopen bug
Mark bug as VERIFIED

View Bug Activity   |   Format For Printing


Description:   Last confirmed: 0000-00-00 00:00 Opened: 2004-09-15 16:33
The POSIX standard explicitly requires the function to return EAGAIN if the
system lacks a resource to create the new thread. But when the function lacks
memory, the returned error code is ENOMEM.

------- Additional Comment #1 From Ulrich Drepper 2004-09-26 12:13 -------
I don't think there is any case left where ENOMEM is returned.  If yes, provide
a test case.

------- Additional Comment #2 From Matthew Montgomery 2007-03-29 21:11 -------
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


------- Additional Comment #3 From Anton Ghiugan 2007-06-13 20:37 -------
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.... 

------- Additional Comment #4 From Ulrich Drepper 2007-10-07 22:13 -------
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.

------- Additional Comment #5 From Halesh S 2008-07-03 13:52 -------
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






------- Additional Comment #6 From Halesh S 2008-07-03 13:53 -------
Created an attachment (id=2813)
test case

Test Case

------- Additional Comment #7 From Halesh S 2008-07-03 13:53 -------
Created an attachment (id=2814)
patch to fix the issue

------- Additional Comment #8 From Ulrich Drepper 2008-07-26 23:51 -------
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.

     Query page      Enter new bug
Actions: New | Query | bug # | Reports | Requests   New Account | Log In