[Bug nptl/386] pthread_create returns ENOMEM but should return EAGAIN

[Bug nptl/386] pthread_create returns ENOMEM but should return EAGAIN

[jhaberman at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=386

Josh Haberman <jhaberman at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |jhaberman at gmail dot com
         Resolution|WORKSFORME                  |

--- Comment #9 from Josh Haberman <jhaberman at gmail dot com> 2011-05-10 00:27:37 UTC ---
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).

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug nptl/386] pthread_create returns ENOMEM but should return EAGAIN

[drepper.fsp at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=386

Ulrich Drepper <drepper.fsp at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #10 from Ulrich Drepper <drepper.fsp at gmail dot com> 2011-05-11 22:24:22 UTC ---
(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.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug nptl/386] pthread_create returns ENOMEM but should return EAGAIN

[jackie.rosen at hushmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=386

Jackie Rosen <jackie.rosen at hushmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jackie.rosen at hushmail dot com

--- Comment #11 from Jackie Rosen <jackie.rosen at hushmail dot com> ---
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Page where seen: http://volichat.com/adult-chat-rooms
Marked for reference. Resolved as fixed @bugzilla.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/386] pthread_create returns ENOMEM but should return EAGAIN

[schwab at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=386

Andreas Schwab <schwab at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|jackie.rosen at hushmail dot com   |

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/386] pthread_create returns ENOMEM but should return EAGAIN

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  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.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |WORKSFORME


http://sourceware.org/bugzilla/show_bug.cgi?id=386

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug nptl/386] pthread_create returns ENOMEM but should return EAGAIN

[halesh dot s at gmail dot com]

------- Additional Comments From halesh dot s at gmail dot com  2008-07-03 13:53 -------
Created an attachment (id=2813)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=2813&action=view)
test case

Test Case

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=386

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug nptl/386] pthread_create returns ENOMEM but should return EAGAIN

[halesh dot s at gmail dot com]

------- Additional Comments From halesh dot s at gmail dot com  2008-07-03 13:53 -------
Created an attachment (id=2814)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=2814&action=view)
patch to fix the issue


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=386

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug nptl/386] pthread_create returns ENOMEM but should return EAGAIN

[halesh dot s at gmail dot com]

------- Additional Comments From halesh dot s at gmail dot com  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







-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WORKSFORME                  |


http://sourceware.org/bugzilla/show_bug.cgi?id=386

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug nptl/386] pthread_create returns ENOMEM but should return EAGAIN

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  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.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |WORKSFORME


http://sourceware.org/bugzilla/show_bug.cgi?id=386

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug nptl/386] pthread_create returns ENOMEM but should return EAGAIN

[anton_ghiugan at ml dot com]

------- Additional Comments From anton_ghiugan at ml dot com  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.... 

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=386

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug nptl/386] pthread_create returns ENOMEM but should return EAGAIN

[mmontgomery at mysql dot com]

------- Additional Comments From mmontgomery at mysql dot com  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



-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |


http://sourceware.org/bugzilla/show_bug.cgi?id=386

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug nptl/386] pthread_create returns ENOMEM but should return EAGAIN

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2004-09-26 12:13 -------
I don't think there is any case left where ENOMEM is returned.  If yes, provide
a test case.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://sources.redhat.com/bugzilla/show_bug.cgi?id=386

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.