From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5036 invoked by alias); 23 Mar 2012 21:33:33 -0000 Received: (qmail 5027 invoked by uid 22791); 23 Mar 2012 21:33:31 -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 21:33:21 +0000 From: "ppluzhnikov at google 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 22:07: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: ppluzhnikov at google dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org 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/msg00301.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=11787 --- Comment #6 from Paul Pluzhnikov 2012-03-23 21:32:30 UTC --- (In reply to comment #5) Carlos, I don't believe you've understood the problem. Default stack sizes are fine. But aio_write creates a small (16K) stack, and chrome creates 128K stacks. Normally this is also just fine; and all works. But then application creates a larger-than-usual TLS (either by allocating 4096 thread-local ints as in the test case here, or by instrumenting for profiling), and suddenly things start crashing in hard-to-diagnose fashion. > We do not want to penalize all of the other programs that don't need the extra > stack space. You aren't penalizing them much if they aren't using TLS, and if they are using large TLS, then you are making them work instead of crashing. >>From "man pthread_attr_setstacksize": The pthread_attr_setstacksize() function sets the stack size attribute of the thread attributes object referred to by attr to the value specified in stacksize. It doesn't say "to the value specified in stacksize minus the size of TLS". The fact that GLIBC chops off space for TLS from the top of stack is an implementation detail, and (IMHO) should *not* reduce the stack size application actually gets! -- 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.