From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 36177 invoked by alias); 20 Nov 2019 00:35:14 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 36164 invoked by uid 89); 20 Nov 2019 00:35:13 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.1 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.1 spammy= X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 20 Nov 2019 00:35:11 +0000 Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 2B75C1E5F1; Tue, 19 Nov 2019 19:35:09 -0500 (EST) Subject: Re: [PATCH] Fix infinite recursion bug at get_msymbol_address. To: Ali Tamur Cc: gdb-patches@sourceware.org, Tom Tromey , Eric Christopher References: <20191107040541.208168-1-tamur@google.com> <8348cd40-ec26-731b-2b41-76ffc1f1886c@simark.ca> From: Simon Marchi Message-ID: <2687bea9-13b0-bf28-069c-d7bcc746d903@simark.ca> Date: Wed, 20 Nov 2019 00:35:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-11/txt/msg00615.txt.bz2 On 2019-11-19 7:02 p.m., Ali Tamur via gdb-patches wrote: > Hi Simon, > > We have some hooks into gdb's "new objfile" event, where we optionally load > related debug files from somewhere else. Thanks, and does it happen for the "new objfile" event for the main objfile (the main executable), or for the "new objfile" event for another objfile (a shared library)? >The failing test involves these > hooks and reducing it further is proving difficult. I put a breakpoint just > before entering the loop: > > CORE_ADDR > > get_msymbol_address (struct objfile *objf, const struct minimal_symbol > > *minsym) { > > gdb_assert (minsym->maybe_copied); > > gdb_assert ((objf->flags & OBJF_MAINLINE) == 0); > > const char *linkage_name = MSYMBOL_LINKAGE_NAME (minsym); > > for (objfile *objfile : current_program_space->objfiles ()) { > > if ((objfile->flags & OBJF_MAINLINE) != 0) { > > bound_minimal_symbol found = lookup_minimal_symbol_linkage > > (linkage_name, objfile); > >
if (found.minsym != nullptr) return BMSYMBOL_VALUE_ADDRESS (found); > > } > > } > > return (minsym->value.address + ANOFFSET (objf->section_offsets, > > minsym->section)); > > } > > (top-gdb) c > > (top-gdb) p objf > > $12 = (objfile *) 0x1a5dae0 > > (top-gdb) p minsym > > $13 = (const minimal_symbol *) 0x7ffff70fff88 > > (top-gdb) p objf->flags > > $14 = {m_enum_value = (OBJF_REORDERED | OBJF_USERLOADED | > > OBJF_PSYMTABS_READ)} For this objfile, it would be interesting to print the objfile::separate_debug_objfile_backlink to know if it represents a separate debug information objfile or not. In fact, if you could provide "print objf" as well as "print *objf", it would help. > (top-gdb) p objfile > > $15 = (objfile *) 0x1928000 > > (top-gdb) p objfile->flags > > $16 = {m_enum_value = (OBJF_REORDERED | OBJF_USERLOADED | > > OBJF_PSYMTABS_READ | OBJF_MAINLINE)} Same thing for this objfile, both "print objfile" and "print *objfile". > (top-gdb) p found > > $17 = {minsym = 0x7ffff70fff88, objfile = 0x1a5dae0} > > So, objfile and objf are different objects. We call > lookup_minimal_symbol_linkage(linkage_name, objfile), it iterates through > objfile->separate_debug_objfiles() and returns the original objf and minsym. > > The stack trace is like this: > > #0 get_msymbol_address (objf=0x1a5dae0, minsym=0x7ffff70fff88) at > > gdb/symtab.c:6306 > > #1 0x0000000000c98b1e in lookup_minimal_symbol_by_pc_name (pc=0x10d120, > > name=0x1c86990 "main(int, char**)", objf=0x1a5dae0) at gdb/minsyms.c:613 > > #2 0x0000000000e090d8 in fixup_section (ginfo=0x1d42af0, addr=0x10d120, > > objfile=0x1a5dae0) at gdb/symtab.c:1649 > > #3 0x0000000000e09577 in fixup_symbol_section (sym=0x1d42af0, > > objfile=0x1a5dae0) at gdb/symtab.c:1759 > > #4 0x0000000000e16401 in lookup_symbol_via_quick_fns (objfile=0x1a5dae0, > > block_index=GLOBAL_BLOCK, > > name=0x1f995b0 "main", domain=VAR_DOMAIN) at gdb/symtab.c:2408 > > #5 0x0000000000e0ab30 in lookup_symbol_in_objfile (objfile=0x1a5dae0, > > block_index=GLOBAL_BLOCK, > > name=0x1f995b0 "main", domain=VAR_DOMAIN) at gdb/symtab.c:2530 Could you provide the full stack trace please? Ideally as an attached file, as your email client seems to wrap the lines in a way that makes them hard to read. > I don't know whether what we are doing breaks too many assumptions: > > * already have a debug file and load an equivalent one again? > > * have two debug files that define the same symbol? > > * something else? My intuition is that the two objfiles above are related, one would be the separate debug file for the other. If you provide the info I requested above we'll be able to tell. > but my patch with a simple guard against infinite recursion seems to work > well enough. It gets rid of the symptoms of the problem, but we don't know if it gets rid of the problem. Maybe it does, but we need to understand what happens first. Simon