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.
This commit is contained in:
Doug Evans 2014-05-20 13:06:26 -07:00
parent 39128ec026
commit 227533ac01
2 changed files with 15 additions and 1 deletions

View File

@ -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.

View File

@ -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;