Re: [PATCH] Fix PR 21337 v2: segfault when re-reading symbols with remote debugging.

[Simon Marchi <simon dot marchi at polymtl dot ca>]

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  <Doug.Gilmore@Doug.Gilmore@imgtec.com>
>
> 	* 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