From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30991 invoked by alias); 23 Nov 2013 09:20:20 -0000 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 Received: (qmail 30916 invoked by uid 48); 23 Nov 2013 09:20:15 -0000 From: "david.abdurachmanov at gmail dot com" To: glibc-bugs@sourceware.org Subject: [Bug libc/11787] Program with large TLS segments fail. Date: Sat, 23 Nov 2013 09:20: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-Version: 2.12 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: david.abdurachmanov at gmail dot com X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: carlos at redhat dot com X-Bugzilla-Target-Milestone: 2.18 X-Bugzilla-Flags: review+ X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-11/txt/msg00250.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=11787 --- Comment #39 from David Abdurachmanov --- The same test case fails on glibc 2.5 (RHEL 5.10), but that is expected. I have an application, which dlopens plugins. It happens to be that dlopen fails with new plugins, "cannot allocate memory in static TLS block". I found some big TLS segments, e.g., 1296, 498, and 3068448. It happens that plugins consumes 3+MB of TLS. Looking at glibc 2.5 code, TLS size seems to be 1664+ bytes. I used private symbol, _dl_get_tls_static_info, to get some information about TLS from plugin manager and it always returned 3760 as TLS size. I did not manage to find a way to get _dl_tls_static_used. I do assume "cannot allocate memory in static TLS block" is related to huge TLS segments size. It most likely doesn't fit into TLS space. Is there a quick way to confirm this, or I need to debug dynamic loader? glibc Release/2.18 wiki: https://sourceware.org/glibc/wiki/Release/2.18 In "1.2. Desirable this release?": BZ#11787 - Programs with large TLS segment fail (Carlos) A workaround here is going to be to use Siddhesh's new LIBC_PTHREAD_DEFAULT_STACK_SIZE env var to bump up default stack sizes. The fix is not in 2.18 as I understood, any progress for 2.19? -- You are receiving this mail because: You are on the CC list for the bug.