From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23874 invoked by alias); 28 Oct 2014 13:32:46 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 23861 invoked by uid 89); 28 Oct 2014 13:32:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Message-ID: <544F9AF4.2050409@redhat.com> Date: Tue, 28 Oct 2014 13:32:00 -0000 From: "Carlos O'Donell" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Will Newton CC: Roland McGrath , GNU C Library Subject: Re: Should glibc be fully reentrant? What do we allow interposed symbols to do? References: <54456FA1.9070804@redhat.com> <20141020204153.83C542C3B0D@topped-with-meat.com> <54457C4C.4080307@redhat.com> <20141021224739.080382C3AB2@topped-with-meat.com> <54486800.4040806@redhat.com> <54491354.40507@redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-10/txt/msg00656.txt.bz2 On 10/28/2014 08:24 AM, Will Newton wrote: >> If you can write a test case I will look at it. > > I had mis-remembered the details of the issue. What I did find was > that using LD_PRELOAD to override malloc and calling dlsym can be a > problem. This was caused by the following code in dlfcn/dlerror.c: Thanks for looking! > /* We don't use the static buffer and so we have a key. Use it > to get the thread-specific buffer. */ > result = __libc_getspecific (key); > if (result == NULL) > { > result = (struct dl_action_result *) calloc (1, sizeof (*result)); > if (result == NULL) > /* We are out of memory. Since this is no really critical > situation we carry on by using the global variable. > This might lead to conflicts between the threads but > they soon all will have memory problems. */ > result = &last_result; > else > /* Set the tsd. */ > __libc_setspecific (key, result); > > The calloc call can cause a loop and overflow the stack. If you use a > malloc hook and enable/disable the hook correctly then everything is > OK I think. Right, this is a developer problem. Infinite loops are your own fault. You need to detect them and terminate the recursion with memory from a static buffer or the original malloc. There isn't any other solution I can suggest. Does that make sense? Cheers, Carlos.