From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) by sourceware.org (Postfix) with ESMTP id AEEFB38930E7 for ; Tue, 26 May 2020 18:09:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org AEEFB38930E7 Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-276-lDcfxtgcMmWbN1IdO-Q_aQ-1; Tue, 26 May 2020 14:09:37 -0400 X-MC-Unique: lDcfxtgcMmWbN1IdO-Q_aQ-1 Received: by mail-wr1-f71.google.com with SMTP id c14so314676wrw.11 for ; Tue, 26 May 2020 11:09:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=336x1+KjlFQ5g/qQftlvA2+aUWWq6z6kDsARHWrycmQ=; b=gXl9QAbgFw1MXTbhtVVa30QMnWlKjLen35EyMyc7KCAQKUF/mGBCsu43HtYYJNhAhC uphBu6fuEPA6CXJ+DDkc82AD7ZNDGW5V7O9LUD8dhai9XIEuY0RqhKrcHyZQ46dHKRBW ZupSl286hEHL1FDWUE8AynWTHE7szV9zZfb0Y1N2N/KwFKsx8ZUW+1q+cfBN5Xj2KbiL Eh8yDc4IMfk/QFAsAGaoEbHvwuBBU2eArAm+D0dqYCEONXN3GigVwnkbrGuMuj7b0ekI 6fElC2S16GQ71Ltfi1w6VCS+frSdAltpjmcHFeVuOMAx7uB41SXFVh61SXXTfZVSLW2W QpqA== X-Gm-Message-State: AOAM533tOeVrZu/1VX8RIOE/4KIS9EYStmbiU75+xFeh33/eB1O7eOfX fYbDkP2vUviASmeznIX67Du8Np0uFQAW+ncuMMdfVMm/rjRQ9Ei1fVZYs/MD8b6qSCmOgiHWssF ik4k6e+RO1oj0f6Km7MTFug== X-Received: by 2002:adf:9507:: with SMTP id 7mr20732666wrs.63.1590516576398; Tue, 26 May 2020 11:09:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwgDECN8Lxehsl3P55kqVy7gIUEpp7NU03ZRM7zeKo8XGhctUQxMH1hvRuswP0bktCLlLZ4XQ== X-Received: by 2002:adf:9507:: with SMTP id 7mr20732656wrs.63.1590516576223; Tue, 26 May 2020 11:09:36 -0700 (PDT) Received: from ?IPv6:2001:8a0:f909:7b00:56ee:75ff:fe8d:232b? ([2001:8a0:f909:7b00:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id x186sm304704wmg.8.2020.05.26.11.09.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 May 2020 11:09:35 -0700 (PDT) Subject: Re: GDB crash due to infinite recursion in typedef substitution (Re: [PATCHv2 3/3] gdb: Remove C++ symbol aliases from completion list) To: Andrew Burgess References: <4acf4e31571f81bdb0199d78ed7e1e93b41b5a31.1580171514.git.andrew.burgess@embecosm.com> <70063d9a-3bc0-c56f-49dd-0060a6d214b0@redhat.com> <20200526170245.GV3522@embecosm.com> Cc: gdb-patches@sourceware.org, Keith Seitz From: Pedro Alves Message-ID: <0d93cb84-3485-57d0-173f-23c5fc7633a8@redhat.com> Date: Tue, 26 May 2020 19:09:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20200526170245.GV3522@embecosm.com> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2020 18:09:41 -0000 On 5/26/20 6:02 PM, Andrew Burgess wrote: > * Pedro Alves [2020-05-25 15:34:27 +0100]: > >>> Anyone else seeing this? >> >> I'm also seeing this when I build GDB with GCC 10 (and debug >> that GDB with itself), so it must be others see this too? > > Yes I can reproduce the original issue you are seeing trying to > complete on main. > Ah, cool. With current master completing on main should no longer crash, but you should be able to see it with: "gdb gdb::option::[TAB]" > You also mentioned a couple of times seeing problems with the test > gdb.linespec/cp-completion-aliases.exp, this I don't see - you said > even with the patch you already pushed you were still seeing issues > with this test, and I can't reproduce this. I don't think I ever said that. ISTR someone else mentioning seeing problems with completion tests on the list (Tom de Vries?). Most (all?) completion tests got broken with the completion styling. But Tromey reversed that feature so that testsuite breakage should be fixed now. > > Still I think your first patch looks like a nice improvement, so > thanks for that. The patch below looks like a good solution to me, I > only had one tiny bit of feedback... > >> > I don't know if you should be using make_scoped_restore to protect > info->current_scope? Yeah, probably. However, I'm still not clear on whether this is the right fix. I think we should see what happens if a typedef is really substituted. If, say, we really found a typedef called "boolean_option_def" under gdb::option, what will the name of that resolved typedef be? I suppose it will be a fully qualified name, and thus back in replace_typedefs_qualified_name we should be replacing the whole qualified name with the new resolved name? And what if inspect_type resolves a typedef, and then recurses again into replace_typedefs? Will leaving info->current_scope as "gdb::option::" break that? Thanks, Pedro Alves