From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99640 invoked by alias); 22 Apr 2017 02:15:53 -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 98093 invoked by uid 89); 22 Apr 2017 02:15:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-23.9 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=ham version=3.3.2 spammy=H*UA:Roundcube, H*u:Webmail, H*u:Roundcube, 5710 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; Sat, 22 Apr 2017 02:15:26 +0000 Received: by simark.ca (Postfix, from userid 33) id 961451E4BD; Fri, 21 Apr 2017 22:15:08 -0400 (EDT) To: Doug Gilmore Subject: Re: [PATCH] Fix PR 21337 v2: segfault when re-reading symbols with remote debugging. X-PHP-Originating-Script: 33:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 22 Apr 2017 02:15:00 -0000 From: Simon Marchi Cc: Luis Machado , gdb-patches@sourceware.org In-Reply-To: <3c5ce0a0-72e5-4460-5555-ad2214866260@imgtec.com> References: <20511c76-c816-d31d-5144-749eac9fc470@imgtec.com> <3c5ce0a0-72e5-4460-5555-ad2214866260@imgtec.com> Message-ID: <5c494cc147f71dd8246572aa0b815c9f@polymtl.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.2.4 X-IsSubscribed: yes X-SW-Source: 2017-04/txt/msg00623.txt.bz2 On 2017-04-13 14:56, Doug Gilmore wrote: > I updated and rebased the patch per Luis's comments in: > > https://www.sourceware.org/ml/gdb-patches/2017-04/msg00361.html > > which I attached. Could a global maintainer review it when they have > the chance? The problem is only exposed on MIPS, however the patch > involves changing code that is not MIPS specific. > > Thanks, > > Doug > > gdb/ > > 2017-??-?? Doug Gilmore > > * symfile.c (reread_symbols): Fix PR 21337. > --- > gdb/symfile.c | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/gdb/symfile.c b/gdb/symfile.c > index 846aabe..d57563d 100644 > --- a/gdb/symfile.c > +++ b/gdb/symfile.c > @@ -2576,6 +2576,12 @@ reread_symbols (void) > /* Free the obstacks for non-reusable objfiles. */ > psymbol_bcache_free (objfile->psymbol_cache); > objfile->psymbol_cache = psymbol_bcache_init (); > + > + /* Notify objfiles that we've modified objfile sections, which now > + needs to be done early to ensure that, for the MIPS target, > + find_pc_section won't access stale data. */ > + objfiles_changed (); > + > obstack_free (&objfile->objfile_obstack, 0); > objfile->sections = NULL; > objfile->compunit_symtabs = NULL; > @@ -2660,9 +2666,6 @@ reread_symbols (void) > > if (!new_objfiles.empty ()) > { > - /* Notify objfiles that we've modified objfile sections. */ > - objfiles_changed (); > - > clear_symtab_users (0); > > /* clear_objfile_data for each objfile was called before freeing > it and I don't have the required knowledge to review this properly, but I have a question. From the attachment in Bugzilla, the backtrace where the crash happens is: ==19949== at 0x64D827: bsearch_cmp(void const*, void const*) (objfiles.c:1415) ==19949== by 0x559D247: bsearch (stdlib-bsearch.h:33) ==19949== by 0x64D9E3: find_pc_section(unsigned long) (objfiles.c:1462) ==19949== by 0x643BDE: lookup_minimal_symbol_by_pc(unsigned long) (minsyms.c:785) ==19949== by 0x40852B: mips_pc_is_mips(unsigned long) (mips-tdep.c:1183) ==19949== by 0x4086EA: mips_adjust_dwarf2_addr(unsigned long) (mips-tdep.c:1271) ==19949== by 0x5E0F98: gdbarch_adjust_dwarf2_addr(gdbarch*, unsigned long) (gdbarch.c:3369) ==19949== by 0x5A24E5: read_attribute_value(die_reader_specs const*, attribute*, unsigned int, long, unsigned char const*) (dwarf2read.c:16570) ==19949== by 0x5A2E2E: read_attribute(die_reader_specs const*, attribute*, attr_abbrev*, unsigned char const*) (dwarf2read.c:16796) ==19949== by 0x59FA76: read_full_die_1(die_reader_specs const*, die_info**, unsigned char const*, int*, int) (dwarf2read.c:15537) ==19949== by 0x59FAEB: read_full_die(die_reader_specs const*, die_info**, unsigned char const*, int*) (dwarf2read.c:15556) ==19949== by 0x587B9A: init_cutu_and_read_dies(dwarf2_per_cu_data*, abbrev_table*, int, int, void (*)(die_reader_specs const*, unsigned char const*, die_info*, int, void*), void*) (dwarf2read.c:5710) I'd be curious to see the rest of that backtrace to understand better when/why it blows up. It looks like you can use --num-callers with valgrind, or simply use GDB :). Simon