diff options
author | Doug Evans <dje@google.com> | 2014-05-20 13:06:26 -0700 |
---|---|---|
committer | Doug Evans <dje@google.com> | 2014-05-20 13:06:26 -0700 |
commit | 227533ac014354eaba944795cf8ff9cb3a31d330 (patch) | |
tree | 110b109b020e820371df7da3c1b21606667e111e | |
parent | 39128ec026ca07a3a1cf2c2096afb3f17fa1d5d8 (diff) | |
download | gdb-227533ac014354eaba944795cf8ff9cb3a31d330.zip gdb-227533ac014354eaba944795cf8ff9cb3a31d330.tar.gz gdb-227533ac014354eaba944795cf8ff9cb3a31d330.tar.bz2 |
Fix gdb.multi/base.exp failures.
UNRESOLVED: gdb.multi/base.exp: remove-inferiors 2-3
UNRESOLVED: gdb.multi/base.exp: check remove-inferiors
gdb is crashing because it's accessing/freeing already freed memory.
==16368== Invalid read of size 4
==16368== at 0x660A9D: find_pc_section (binutils-gdb/gdb/objfiles.c:1349)
==16368== by 0x663ECB: lookup_minimal_symbol_by_pc_section (binutils-gdb/gdb/minsyms.c:734)
==16368== by 0x5D987A: find_pc_sect_symtab (binutils-gdb/gdb/symtab.c:2153)
==16368== by 0x5D4D77: blockvector_for_pc_sect (binutils-gdb/gdb/block.c:168)
==16368== by 0x5D4F59: block_for_pc_sect (binutils-gdb/gdb/block.c:246)
==16368== by 0x5D4F9B: block_for_pc (binutils-gdb/gdb/block.c:258)
==16368== by 0x734C5D: inline_frame_sniffer (binutils-gdb/gdb/inline-frame.c:218)
==16368== by 0x732104: frame_unwind_try_unwinder (binutils-gdb/gdb/frame-unwind.c:108)
==16368== by 0x73223F: frame_unwind_find_by_frame (binutils-gdb/gdb/frame-unwind.c:159)
==16368== by 0x72D5AA: compute_frame_id (binutils-gdb/gdb/frame.c:453)
==16368== by 0x7300EC: get_prev_frame_if_no_cycle (binutils-gdb/gdb/frame.c:1758)
==16368== by 0x73079A: get_prev_frame_always (binutils-gdb/gdb/frame.c:1931)
==16368== Address 0x5b13500 is 16 bytes inside a block of size 24 free'd
==16368== at 0x403072E: free (valgrind/coregrind/m_replacemalloc/vg_replace_malloc.c:445)
==16368== by 0x762134: xfree (binutils-gdb/gdb/common/common-utils.c:108)
==16368== by 0x65DACF: objfiles_pspace_data_cleanup (binutils-gdb/gdb/objfiles.c:91)
==16368== by 0x75E546: program_spaceregistry_callback_adaptor (binutils-gdb/gdb/progspace.c:45)
==16368== by 0x7644F6: registry_clear_data (binutils-gdb/gdb/registry.c:82)
==16368== by 0x7645AB: registry_container_free_data (binutils-gdb/gdb/registry.c:95)
==16368== by 0x75E5B4: program_space_free_data (binutils-gdb/gdb/progspace.c:45)
==16368== by 0x75E9BA: release_program_space (binutils-gdb/gdb/progspace.c:167)
==16368== by 0x75EB9B: prune_program_spaces (binutils-gdb/gdb/progspace.c:269)
==16368== by 0x75303D: remove_inferior_command (binutils-gdb/gdb/inferior.c:792)
==16368== by 0x50B5FD: do_cfunc (binutils-gdb/gdb/cli/cli-decode.c:107)
==16368== by 0x50E6F2: cmd_func (binutils-gdb/gdb/cli/cli-decode.c:1886)
The problem originates from the get_current_arch call in
py-progspace.c:py_free_pspace. The inferior associated with the
pspace is gone, and the current inferior is a different one and is running.
Therefore get_current_arch tries to read the current frame which
causes reads of data in the current program space which we've just deleted.
* python/py-progspace.c (py_free_pspace): Call target_gdbarch
instead of get_current_arch.
-rw-r--r-- | gdb/ChangeLog | 5 | ||||
-rw-r--r-- | gdb/python/py-progspace.c | 11 |
2 files changed, 15 insertions, 1 deletions
diff --git a/gdb/ChangeLog b/gdb/ChangeLog index ece66c2..0c87bff 100644 --- a/gdb/ChangeLog +++ b/gdb/ChangeLog @@ -1,3 +1,8 @@ +2014-05-20 Doug Evans <dje@google.com> + + * python/py-progspace.c (py_free_pspace): Call target_gdbarch + instead of get_current_arch. + 2014-05-20 Pedro Alves <palves@redhat.com> * NEWS: Mention that compare-sections now works with all targets. diff --git a/gdb/python/py-progspace.c b/gdb/python/py-progspace.c index cda5a86..db4c564 100644 --- a/gdb/python/py-progspace.c +++ b/gdb/python/py-progspace.c @@ -241,7 +241,16 @@ py_free_pspace (struct program_space *pspace, void *datum) { struct cleanup *cleanup; pspace_object *object = datum; - struct gdbarch *arch = get_current_arch (); + /* This is a fiction, but we're in a nasty spot: The pspace is in the + process of being deleted, we can't rely on anything in it. Plus + this is one time when the current program space and current inferior + are not in sync: All inferiors that use PSPACE may no longer exist. + We don't need to do much here, and since "there is always an inferior" + using target_gdbarch suffices. + Note: We cannot call get_current_arch because it may try to access + the target, which may involve accessing data in the pspace currently + being deleted. */ + struct gdbarch *arch = target_gdbarch (); cleanup = ensure_python_env (arch, current_language); object->pspace = NULL; |