From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 129620 invoked by alias); 10 Dec 2018 15:18:16 -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 129594 invoked by uid 89); 10 Dec 2018 15:18:15 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,KAM_NUMSUBJECT,KAM_SHORT,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=toward, depth, recursion_level, H*f:sk:B6beozo X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 10 Dec 2018 15:18:09 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 91B7351145; Mon, 10 Dec 2018 15:18:08 +0000 (UTC) Received: from ovpn-117-98.phx2.redhat.com (ovpn-117-98.phx2.redhat.com [10.3.117.98]) by smtp.corp.redhat.com (Postfix) with ESMTP id D97565D962; Mon, 10 Dec 2018 15:18:05 +0000 (UTC) Message-ID: <1544455085.4619.179.camel@redhat.com> Subject: Re: [PATCH] Set DEMANGLE_RECURSION_LIMIT to 1536 From: David Malcolm To: Michael Matz , Nick Clifton Cc: Ian Lance Taylor , "H.J. Lu" , Pedro Alves , Richard Guenther , Jakub Jelinek , sgayou@redhat.com, Tom Tromey , GCC Patches , Binutils , Jason Merrill Date: Mon, 10 Dec 2018 15:18:00 -0000 In-Reply-To: References: <87muprdko7.fsf@redhat.com> <20181130084211.GX12380@tucnak> <173817ca-0aa0-e1a2-6725-37e079ead545@redhat.com> <20181130140330.GA12380@tucnak> <460cb971-0e21-1e3e-4920-8b3ee7290cf7@redhat.com> <736e8303-b724-f96d-54f5-46bff99fa34d@redhat.com> <57d33aa7-4e37-a09c-4bdc-974b5f654d33@redhat.com> <2f4c983b-494f-93ba-d6c6-1fe0a9730a76@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-12/txt/msg00580.txt.bz2 On Mon, 2018-12-10 at 14:52 +0000, Michael Matz wrote: > Hi, > > 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? Apologies in advance if this has been covered, as I've only been half- watching this thread, but is it always the case that the recursion depth can be bounded by some scalar multiple of the number of characters in the name? The name that's causing trouble is 654 characters long, and the proposed limit of 1306 is slightly below double that. There may well be a bug in the implementation as Michael points out, but is the recursion depth always guaranteed to be less than 2 * num_chars seen, or somesuch limit. If so, could the limit be dynamic, rather than hardcoded? That would trap cases where we're consuming stack frames without consuming input characters, and eliminate having a hardcoded limit that's bound to eventually become wrong as people write more and more complicated C++ programs. Hope this is constructive Dave