Pthread Create Error Code 12
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 https://www.parkes.atnf.csiro.au/observing/documentation/computing_notes/linux_threads.html bytes, text/plain) 2008-07-03 13:53 UTC, Halesh S Details patch to fix the issue (443 bytes, patch) 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 https://sourceware.org/bugzilla/show_bug.cgi?id=386 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. 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
by CloudFlare Ray ID: 2f7073d255ca37b6
to the Single Unix Specification standard consisted to submit an example of use for pthread_sigmask()[1]. Since my proposal was going to be viewed by many Austin Group's contributors (some being "recognized UNIX authority"), I tried to make my example as perfect as possible. In an academic fashion, I checked every function's return code for possible errors. That's where I got it wrong for the Pthreads APIs. Oh well, they do not use errno… The Problem: Before the advent of Pthreads, POSIX functions used to return -1 on error, and set the corresponding error code in the global variable errno[2]. This mechanism has a few drawbacks even for single-threaded process: it is not simple to return -1 as valid value. a signal handler may change the errno value between the point a function set errno, and the point where you check the errno variable. Of course, a global errno doesn't work for multi-threaded processes. Indeed, a thread could execute a function that modifies errno just before you check the value in another thread. The (Pthreads) Solution: Since Pthreads, the errno variable is thread-local. That is, every thread has its own "errno copy". If you (or a system function) set the errno variable in one thread, it won't affect the errno value in any other thread. This is shown in the example below. Download errno_01.c1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 /*------------------------------ errno_01.c -------------------------------* compile with: cc -pthread errno_01.c -o errno_01 Copyright Loic Domaigne. Licensed under the Apache License, Version 2.0. *--------------------------------------------------------------------------*/ #include