pthread_create fails on a device with 16MB RAM
Carl Shaw
shaw.carl at gmail.com
Fri Jan 28 09:31:37 UTC 2011
On 28/01/11 00:39, Alexander Gordeev wrote:
> Hi!
>
> I have a problem with pthread_create on a device with only 16MB RAM.
> strace shows this:
>
> old_mmap(NULL, 8388608, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
>
> instead of (what I obtained on another device with 32MB RAM):
>
> old_mmap(NULL, 8388608, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 2143089904, 0x2b985918) = 0x2bc6b000
> mprotect(0x2bc6b000, 4096, PROT_NONE) = 0
> clone(child_stack=0x2c46a3b0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x2c46a6f8, tls=0x2c471960, child_tidptr=0) = 1394
>
> which is quite reasonable because 8388608 is greater than half the
> amount of available physical memory which AFAIK is a limit for memory
> allocations normally. When I did
>
> echo 1 > /proc/sys/vm/overcommit_memory
>
> everything worked like a charm (because this limit was disabled).
>
> How can I tune uClibc to not request so much memory on pthread_create?
This occurs because the default maximum stack size is usually 8MB (check
using ulimit -s or -a at a shell prompt).
You have a number of options to change this:
1. Change the default maximum stack size. This can be done in a shell
by using ulimit -s or by using the setrlimit() C lib function call with
RLIMIT_STACK option. You can set an explicit value (16 kiB min) or if
you set it to RLIM_INFINITY then a architecture-dependent default size
will be used (in NPTL this is defined in sysdeps/<arch>/pthreaddef.h in
ARCH_STACK_DEFAULT_SIZE in linuxthreads the header file is pt-machine.h)
2. Allocate your own stack memory, insert into to a thread attribute
structure using pthread_attr_setstack() and use that when creating the
thread with pthread_create()
3. Patch the C library to use a more appropriate default rather than
calling getrlimit(RLIMIT_STACK)!
Cheers,
Carl
More information about the uClibc
mailing list