Jan Just, *, good day.
Fri, Oct 10, 2008 at 01:01:31PM +0200, Jan Just Keijser wrote:
> this is interesting behaviour indeed, and affects *ALL* threaded
> applications...
>
> $ ulimit -s 1048576
> $ /opt/lcg/bin/lfc-mkdir /grid/pvier/janjust/test
> t2146736864:p10274: Fatal error: [Thread System] GLOBUSTHREAD:
> pthread_create() failed
>
> [Thread System] insufficient memory (ENOMEM)Aborted
>
> $ ulimit -s 40000
> $ /opt/lcg/bin/lfc-mkdir /grid/pvier/janjust/test
> < command runs fine >
>
> the system default is to have an ulimited stack size so that case is
> apparently treated differently...
The problem is that pthread_create invokes allocate_stack() that tries
to mmap() the buffer for the stack. The stack size is determined by
either the passed contents of pthread_attr_t (the second argument) or by
the default stack size that is determined precisely from the system's
limit.
When system's limit is RLIM_INFINITY, pthreads library uses
ARCH_STACK_DEFAULT_SIZE that varies from 2M (i386) to 32M (ia64),
so no breakage is seen.
> this means that this is *NOT* an lfc bug , unless people agree that the
> 'lfc-mkdir' command should not be pthreaded-based ...
No, this can be fixed if pthread_attr_setstack() will be used. Although
it depends of the situation with the lfc programs -- may be it is
unsuitable for them to allocate the stack for the threads by themselves.
But allocating 1G is insanity -- lfc utilities won't create such a
horrible amount of threads to use all available stack ;))
--
Eygene Ryabinkin, Russian Research Centre "Kurchatov Institute"
|