From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19877 invoked by alias); 27 Mar 2012 19:09:33 -0000 Received: (qmail 19808 invoked by uid 22791); 27 Mar 2012 19:09:32 -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; Tue, 27 Mar 2012 19:09:21 +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: Tue, 27 Mar 2012 21:21: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: carlos_odonell at mentor dot com X-Bugzilla-Target-Milestone: 2.16 X-Bugzilla-Changed-Fields: AssignedTo Target Milestone 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/msg00344.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=11787 Carlos O'Donell changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|unassigned at sourceware |carlos_odonell at mentor |dot org |dot com Target Milestone|--- |2.16 --- Comment #23 from Carlos O'Donell 2012-03-27 19:08:13 UTC --- I'm assigning this issue to myself since it seems that nptl/allocatestack.c and nptl/nptl-ini.c need cleanup regarding the definition of stack. The fact that POSIX has a seperate set of functions for getting and setting the guard size indicates that the guard is *not* considered a part of the stack. Not to mention the POSIX wording "the implementation allocates extra memory" means that the current GLIBC implementation isn't correct (but one or two pages doesn't help here). The guard size should be removed from the stack computation. Given that the guard size shouldn't be part of the stack size brings even more doubt on the current practice of placing the static tls and pthread descriptor into the stack. Yet another corner case is that using PTHREAD_STACK_MIN as a minimal stack should get you a thread that starts, but under a system where a variable sized TLS data region is included you are not guaranteed this at all. In fact using PTHREAD_STACK_MIN as a size might or might not work which is in my opinion another failure to meet the principle of "least surprise." I'm asking for some interpretation help from the Austin Group regarding the meaning of stack. -- 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.