Pthread_create Error 12 Enomem

in the non-detached mode, and the limited available memory in some system stack is consumed. At that point no new threads can be created in non-detached mode until those threads are detached/killed, or the parent process(es) killed and restarted. Solution: create the threads in the detached state with the pthread_attr_setdetachstate call, e.g.; pthread_attr_init (&id_attr); pthread_attr_setdetachstate(&id_attr, PTHREAD_CREATE_DETACHED); pthread_create( , &id_attr, , ); unless you really need the threads in the joinable (non-detached) state, in which case you will have a fixed upper limit to the number of joinable threads active at any one time. In the 2.4 kernels I've examined this limit appears to be 256 threads for each parent process(?). Some of this is documented in the man help for pthread_attr_init. However the man help for pthread_create makes no mention of the ENOMEM return and what it means, which is rather confusing. In the Linux 2.2 kernels I've examined the behaviour is slightly different. The system default for the maximum joinable threads alive at any one time seems to be 1024 (rather than 256), and pthread_create returns an error code 11 EAGAIN, and a global errno value of 4 ("Interrupted system call"). The solution is the same as for 2.4: if your process creates lots of threads, make them detached or manage carefully their maximum instantaneous population. John Reynolds December 2004 [an error occurred while processing this directive]

[x] Bug386 - pthread_create returns ENOMEM but should return EAGAIN Summary: pthread_create returns ENOMEM but should return EAGAIN Status: RESOLVED FIXED Alias: None Product: glibc Classification: Unclassified Component: nptl (show other bugs) Version: unspecified Importance: P3 minor Target Milestone: --- Assignee: Ulrich Drepper URL: Keywords: Depends on: Blocks: Reported: 2004-09-15 16:33 UTC by Sebastien Decugis Modified: 2014-05-28 19:44 UTC (History) CC List: 2 users (show) glibc-bugs jhaberman See Also: Host: Target: Build: Last reconfirmed: Attachments test case (274 bytes, text/plain) 2008-07-03 13:53 UTC, Halesh S Details patch to fix the issue (443 bytes, patch) https://www.parkes.atnf.csiro.au/observing/documentation/computing_notes/linux_threads.html 2008-07-03 13:53 UTC, Halesh S Details | Diff View All Add an attachment (proposed patch, testcase, etc.) Note You need to log in before you can comment on or make changes to this bug. Description Sebastien Decugis 2004-09-15 16:33:38 UTC 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 https://sourceware.org/bugzilla/show_bug.cgi?id=386 returned error code is ENOMEM. Comment 1 Ulrich Drepper 2004-09-26 12:13:16 UTC I don't think there is any case left where ENOMEM is returned. If yes, provide a test case. Comment 2 Matthew Montgomery 2007-03-29 21:11:08 UTC 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 Comment 3 Anton Ghiugan 2007-06-13 20:37:42 UTC 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.... Comment 4 Ulrich Drepper 2007-10-07 22:13:37 UTC 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. Comment 5 Halesh S 200

Solution Problem of symbol version Conclusion About the author Introduction The pthread_create() service from the pthread (NPTL) library, may fail returning the ENOMEM or EAGAIN error. This papers focuses on the reason http://rachid.koucha.free.fr/tech_corner/problem_of_thread_creation.html why this could happen and how to solve the problem. Creation of a thread The creation of a thread involves the following steps (output of the strace tool): mmap(NULL, 8388608, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x350dc000 https://bugzilla.redhat.com/show_bug.cgi?id=1068741 mprotect(0x350dc000, 4096, PROT_NONE) = 0 clone(child_stack=0x358db030, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x358db4f8, tls=0x358e2930, child_tidptr=0x358db4f8)= 6927 sched_setscheduler(6927, SCHED_OTHER, { 0 }) = 0 In the preceding output: The mmap() call reserves a memory zone for the thread's stack and its pthread_create error TCB. The default stack size in the pthread library is got fromthe getrlimit() system call with the resource's name RLIMIT_STACK. In our environment, this value is 8 MB. The returned address is 0x350dc000 The call to mprotect() protects a page of memory (4KB long) from the address 0x350dc000 to detect the stack overflows: this is the red zone which triggers a SIGSEGV if it is accessed for reading or writing. The call pthread_create error 12 to clone() creates the thread. It is passed the address of the stack as first parameter : 0x358db030. The stacks grows from the upper addresses to the lower ones. The space between 0x358db030 and 0x358dc000 is for the thread's control block (TCB) and the thread's local storage (TLS). From a virtual memory point of view, the mapping can be seen from /proc//smaps: 350dc000-350dd000 ---p 350dc000 00:00 0 --------> Red zone which ends the stack to detect stack overflows Size: 4 kB Rss: 0 kB Pss: 0 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 0 kB Referenced: 0 kB Swap: 0 kB 350dd000-358dc000 rw-p 350dd000 00:00 0 --------> Stack which grows from the upper to the lower addresses Size: 8188 kB Rss: 8 kB Pss: 8 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 8 kB Referenced: 8 kB The layout of the thread's stack is: Figure 1: Layout of the thread's stack The2.5 versus 2.8 version of the C library The study of the sources related to pthread_create() in the GLIBC 2.5 and 2.8 libraries points out that the service does not return the same error when mmap() fails with the error code ENOMEM. In 2.5, the code related to the stack allocation of the thread

Printing -XML -Clone This Bug -Last Comment First Last Prev Next This bug is not in your last search results. Bug1068741 - [abrt] pthread_create() fails with EAGAIN Summary: [abrt] pthread_create() fails with EAGAIN Status: CLOSED DUPLICATE of bug 1011179 Aliases: None Product: Fedora Classification: Fedora Component: glibc (Show other bugs) Sub Component: --- Version: 20 Hardware: x86_64 Unspecified Priority unspecified Severity unspecified TargetMilestone: --- TargetRelease: --- Assigned To: Carlos O'Donell QA Contact: Fedora Extras Quality Assurance Docs Contact: URL: https://retrace.fedoraproject.org/faf... Whiteboard: abrt_hash:67fc22140d31acf43a7a52dcbaf... Keywords: Duplicates: 1068748 1068755 1068768 1068957 1071300 1071561 1072085 1073553 1076179 (view as bug list) Depends On: Blocks: Show dependency tree /graph Reported: 2014-02-21 14:31 EST by Brian J. Murrell Modified: 2014-03-14 03:22 EDT (History) CC List: 10 users (show) brian.murrell codonell fabiano jakub law mbarnes mcrha mjs pfrankli spoyarek See Also: Fixed In Version: Doc Type: Bug Fix Doc Text: Story Points: --- Clone Of: Environment: Last Closed: 2014-03-03 13:54:31 EST Type: --- Regression: --- Mount Type: --- Documentation: --- CRM: Verified Versions: Category: --- oVirt Team: --- RHEL 7.3 requirements from Atomic Host: Cloudforms Team: --- Attachments (Terms of Use) File: backtrace (100.96 KB, text/plain) 2014-02-21 14:31 EST, Brian J. Murrell no flags Details File: cgroup (172 bytes, text/plain) 2014-02-21 14:31 EST, Brian J. Murrell no flags Details File: core_backtrace (82.26 KB, text/plain) 2014-02-21 14:31 EST, Brian J. Murrell no flags Details File: dso_list (16.23 KB, text/plain) 2014-02-21 14:31 EST, Brian J. Murrell no flags Details File: environ (1.20 KB, text/plain) 2014-02-21 14:31 EST, Brian J. Murrell no flags Details File: limits (1.29 KB, text/plain) 2014-02-21 14:31 EST, Brian J. Murrell no flags Details File: maps (77.51 KB, text/plain) 2014-02-21 14:31 EST, Brian J. Murrell no flags Details File: open_fds (934 bytes, text/plain) 2014-02-21 14:31 EST, Brian J. Murrell no flags Details File: proc_pid_status (944 bytes, text/plain) 2014-02-21 14:31 EST, Brian J. Murrell no flags Details File: var_log_messages (582 bytes, text/plain) 2014-02-21 14:31 EST, Brian J. Murrell no flags Details Add an attachment (proposed patch, testcase, etc.) Groups: None (edit) Description Brian J. Murrell 2014-02-21 14:31:31 EST Description of problem: Trying to start evolution Version-Release number of selected component: evolution-data-server-3.10.4-1.fc20 Additional info: reporter: libreport-2.1.12 backtrace_rating: 4 cmdline: /usr/libexec/evolution