 |
 |
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"