From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69222 invoked by alias); 10 Dec 2018 15:34:21 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 69131 invoked by uid 89); 10 Dec 2018 15:34:20 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=2.3 required=5.0 tests=BAYES_50,KAM_LAZY_DOMAIN_SECURITY,KAM_NUMSUBJECT,KAM_SHORT,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=toward, H*f:sk:fca558b, H*f:sk:B6beozo, H*f:sk:2f4c983 X-HELO: mail-ot1-f66.google.com Received: from mail-ot1-f66.google.com (HELO mail-ot1-f66.google.com) (209.85.210.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 10 Dec 2018 15:34:18 +0000 Received: by mail-ot1-f66.google.com with SMTP id n8so10758100otl.6 for ; Mon, 10 Dec 2018 07:34:18 -0800 (PST) MIME-Version: 1.0 References: <736e8303-b724-f96d-54f5-46bff99fa34d@redhat.com> <57d33aa7-4e37-a09c-4bdc-974b5f654d33@redhat.com> <2f4c983b-494f-93ba-d6c6-1fe0a9730a76@redhat.com> <20181210151020.GA12380@tucnak> In-Reply-To: <20181210151020.GA12380@tucnak> From: Jason Merrill Date: Mon, 10 Dec 2018 15:34:00 -0000 Message-ID: Subject: Re: [PATCH] Set DEMANGLE_RECURSION_LIMIT to 1536 To: Jakub Jelinek Cc: Michael Matz , Nick Clifton , Ian Lance Taylor , "H.J. Lu" , Pedro Alves , Richard Biener , Scott Gayou , Tom Tromey , gcc-patches List , Binutils Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-12/txt/msg00586.txt.bz2 On Mon, Dec 10, 2018 at 10:10 AM Jakub Jelinek wrote: > On Mon, Dec 10, 2018 at 02:52:39PM +0000, Michael Matz wrote: > > On Fri, 7 Dec 2018, H.J. Lu wrote: > > > > > > > On Thu, Dec 6, 2018 at 3:12 AM Nick Clifton wrote: > > > > > > > > > > > > Is the patch OK with you ? > > > > > > > > > > > > > This caused: > > > > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409 > > > > > > > > > > Here is the fix. OK for trunk? > > > > I think this points toward the limit being _much_ too low. With template > > meta programming you easily get these mangled names, it's not even a > > particularly long one. But I'm wondering a bit, without tracing the > > demangler, just looking at the symbol name and demangled result I don't > > readily see where the depth of recursion really is more than 1024, are > > there perhaps some recursion_level-- statements skipped? > > That is because the recursion_level limit isn't hit in this case at all (far > from it). > > What breaks it is this: > > /* PR 87675 - Check for a mangled string that is so long > that we do not have enough stack space to demangle it. */ > if (((options & DMGL_NO_RECURSE_LIMIT) == 0) > /* This check is a bit arbitrary, since what we really want to do is to > compare the sizes of the di.comps and di.subs arrays against the > amount of stack space remaining. But there is no portable way to do > this, so instead we use the recursion limit as a guide to the maximum > size of the arrays. */ > && (unsigned long) di.num_comps > DEMANGLE_RECURSION_LIMIT) > { > /* FIXME: We need a way to indicate that a stack limit has been reached. */ > return 0; > } > where di.num_comps is just strlen (mangled) * 2. Without any analysis > whatsoever, bumping the "recursion" limit will just mean we can process 1.5 > times long names. Either we need more precise analysis on what we are > looking for (how big arrays we'll need) or it needs to be an independent > limit and certainly should allow say 10KB symbols too if they are > reasonable. If the problem is alloca, we could avoid using alloca if the size passes a threshold. Perhaps even use a better data structure than a preallocated array based on a guess about the number of components... Jason