From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31638 invoked by alias); 23 Mar 2012 20:35:47 -0000 Received: (qmail 31507 invoked by uid 22791); 23 Mar 2012 20:35:44 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 23 Mar 2012 20:35:32 +0000 From: "carlos_odonell at mentor dot com" To: glibc-bugs@sources.redhat.com Subject: [Bug libc/11787] Program with large TLS segment fails aio_write Date: Fri, 23 Mar 2012 20:37:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: carlos_odonell at mentor dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: drepper.fsp at gmail dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2012-03/txt/msg00298.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=11787 --- Comment #4 from Carlos O'Donell 2012-03-23 20:34:37 UTC --- I've reviewed the patch sent to the mailing list and provided comments: http://sourceware.org/ml/libc-alpha/2012-03/msg01002.html I just noticed that what I recommended shouldn't be required since the code should already take this into account. Nobody has given any hard numbers about the static TLS size so I'm marking this issue as unconfirmed. Please provide some real-world figures so we know how bad the problem is compared to the default stack size for x86 e.g. 2MB. sysdeps/i386/pthreaddef.h:#define ARCH_STACK_DEFAULT_SIZE (2 * 1024 * 1024) For example code in nptl-init.c tries to take things into account: ~~~ nptl/nptl-inic.c: 414 /* Determine the default allowed stack size. This is the size used 415 in case the user does not specify one. */ 416 struct rlimit limit; 417 if (getrlimit (RLIMIT_STACK, &limit) != 0 418 || limit.rlim_cur == RLIM_INFINITY) 419 /* The system limit is not usable. Use an architecture-specific 420 default. */ 421 limit.rlim_cur = ARCH_STACK_DEFAULT_SIZE; 422 else if (limit.rlim_cur < PTHREAD_STACK_MIN) 423 /* The system limit is unusably small. 424 Use the minimal size acceptable. */ 425 limit.rlim_cur = PTHREAD_STACK_MIN; 426 427 /* Make sure it meets the minimum size that allocate_stack 428 (allocatestack.c) will demand, which depends on the page size. */ 429 const uintptr_t pagesz = GLRO(dl_pagesize); 430 const size_t minstack = pagesz + __static_tls_size + MINIMAL_REST_STACK; 431 if (limit.rlim_cur < minstack) 432 limit.rlim_cur = minstack; 433 434 /* Round the resource limit up to page size. */ 435 limit.rlim_cur = (limit.rlim_cur + pagesz - 1) & -pagesz; 436 __default_stacksize = limit.rlim_cur; ~~~ Note that we check to see that __default_stacksize takes into account __static_tls_size and a minimal rest size (2K on x86). Is the problem that the minimal computed is *still* not enough? -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.