[PATCH] Fix PR 21337 v2: segfault when re-reading symbols with remote debugging.
Simon Marchi
simon.marchi@polymtl.ca
Sat Apr 22 02:15:00 GMT 2017
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
More information about the Gdb-patches
mailing list