From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27965 invoked by alias); 19 May 2014 20:40:03 -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 27954 invoked by uid 89); 19 May 2014 20:40:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pa0-f74.google.com Received: from mail-pa0-f74.google.com (HELO mail-pa0-f74.google.com) (209.85.220.74) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 19 May 2014 20:40:01 +0000 Received: by mail-pa0-f74.google.com with SMTP id rd3so1052633pab.1 for ; Mon, 19 May 2014 13:40:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-type; bh=/bHeZAYxBmItPIs+7h59tMZpLMKaAvtCBAh5I8vA624=; b=LPVQsL83jNXMrxvElLJ+vWRCoR7/90QkfWVqDjTf9BIU7oCFrzNEeoQw+5n2DF+LBz Sllu25S6yFL+S7sNb7MRhT995o2DHgSYTXvSaIizgv9DbMV9vMGiKWkhqHrUP++Ja96v EgT5d/HAi09OsJVDQgAS0SwiVQVi4TotVT0NNEMJIBookYtW0ypkvmZa4RVsKGKTgpKL BMb6wyg5Ca92i73eFJjh4h/vWeA7TWWsNrHzAF+padd7/jnmZ66hCj4HvJacCm2ZqIwj aQYvJRryGYHUv1mNKzv3bdrOyVEHl83sMf5gLjse1DYOIvauDYp4CNL2lbAvnhwhSGvR 1WJw== X-Gm-Message-State: ALoCoQml4Mp0+HpW9Dai7exTRQZQsRbBijPRCv6Kpv3Luq57U+hLcQQKp1bvYZxSKHFF759OkCt/W7qS7SNM8RTG87nx/O3muVtZU9lQHGDTNz+WtvCOeOwgcnTwMId9SIsy6RQ+P7XZ X-Received: by 10.66.240.4 with SMTP id vw4mr16977904pac.10.1400532000055; Mon, 19 May 2014 13:40:00 -0700 (PDT) Received: from corp2gmr1-2.hot.corp.google.com (corp2gmr1-2.hot.corp.google.com [172.24.189.93]) by gmr-mx.google.com with ESMTPS id n43si655751yhe.1.2014.05.19.13.40.00 for (version=TLSv1.1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 19 May 2014 13:40:00 -0700 (PDT) Received: from ruffy.mtv.corp.google.com (ruffy.mtv.corp.google.com [172.17.128.44]) by corp2gmr1-2.hot.corp.google.com (Postfix) with ESMTP id A51795A427D for ; Mon, 19 May 2014 13:39:59 -0700 (PDT) From: Doug Evans To: gdb-patches@sourceware.org Subject: [PATCH] Fix gdb.multi/base.exp, gdb memory corruption Date: Mon, 19 May 2014 20:40:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00376.txt.bz2 Hi. My prune_inferiors patch 2014-05-17 Doug Evans * inferior.c (prune_inferiors): Fix comment. (remove_inferior_command): Call prune_program_spaces. is causing gdb.multi/base.exp to fail: 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. I was running the testsuite all weekend, sorry I only saw this now. E.g. ==16368== Invalid read of size 4 ==16368== at 0x660A9D: find_pc_section (/usr/local/lib/debug/debug-src/obj64/gdb/../../binutils-gdb/gdb/objfiles.c:1349) ==16368== by 0x663ECB: lookup_minimal_symbol_by_pc_section (/usr/local/lib/debug/debug-src/obj64/gdb/../../binutils-gdb/gdb/minsyms.c:734) ==16368== by 0x5D987A: find_pc_sect_symtab (/usr/local/lib/debug/debug-src/obj64/gdb/../../binutils-gdb/gdb/symtab.c:2153) ==16368== by 0x5D4D77: blockvector_for_pc_sect (/usr/local/lib/debug/debug-src/obj64/gdb/../../binutils-gdb/gdb/block.c:168) ==16368== by 0x5D4F59: block_for_pc_sect (/usr/local/lib/debug/debug-src/obj64/gdb/../../binutils-gdb/gdb/block.c:246) ==16368== by 0x5D4F9B: block_for_pc (/usr/local/lib/debug/debug-src/obj64/gdb/../../binutils-gdb/gdb/block.c:258) ==16368== by 0x734C5D: inline_frame_sniffer (/usr/local/lib/debug/debug-src/obj64/gdb/../../binutils-gdb/gdb/inline-frame.c:218) ==16368== by 0x732104: frame_unwind_try_unwinder (/usr/local/lib/debug/debug-src/obj64/gdb/../../binutils-gdb/gdb/frame-unwind.c:108) ==16368== by 0x73223F: frame_unwind_find_by_frame (/usr/local/lib/debug/debug-src/obj64/gdb/../../binutils-gdb/gdb/frame-unwind.c:159) ==16368== by 0x72D5AA: compute_frame_id (/usr/local/lib/debug/debug-src/obj64/gdb/../../binutils-gdb/gdb/frame.c:453) ==16368== by 0x7300EC: get_prev_frame_if_no_cycle (/usr/local/lib/debug/debug-src/obj64/gdb/../../binutils-gdb/gdb/frame.c:1758) ==16368== by 0x73079A: get_prev_frame_always (/usr/local/lib/debug/debug-src/obj64/gdb/../../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 (/usr/local/lib/debug/debug-src/obj64/gdb/../../binutils-gdb/gdb/common/common-utils.c:108) ==16368== by 0x65DACF: objfiles_pspace_data_cleanup (/usr/local/lib/debug/debug-src/obj64/gdb/../../binutils-gdb/gdb/objfiles.c:91) ==16368== by 0x75E546: program_spaceregistry_callback_adaptor (/usr/local/lib/debug/debug-src/obj64/gdb/../../binutils-gdb/gdb/progspace.c:45) ==16368== by 0x7644F6: registry_clear_data (/usr/local/lib/debug/debug-src/obj64/gdb/../../binutils-gdb/gdb/registry.c:82) ==16368== by 0x7645AB: registry_container_free_data (/usr/local/lib/debug/debug-src/obj64/gdb/../../binutils-gdb/gdb/registry.c:95) ==16368== by 0x75E5B4: program_space_free_data (/usr/local/lib/debug/debug-src/obj64/gdb/../../binutils-gdb/gdb/progspace.c:45) ==16368== by 0x75E9BA: release_program_space (/usr/local/lib/debug/debug-src/obj64/gdb/../../binutils-gdb/gdb/progspace.c:167) ==16368== by 0x75EB9B: prune_program_spaces (/usr/local/lib/debug/debug-src/obj64/gdb/../../binutils-gdb/gdb/progspace.c:269) ==16368== by 0x75303D: remove_inferior_command (/usr/local/lib/debug/debug-src/obj64/gdb/../../binutils-gdb/gdb/inferior.c:792) ==16368== by 0x50B5FD: do_cfunc (/usr/local/lib/debug/debug-src/obj64/gdb/../../binutils-gdb/gdb/cli/cli-decode.c:107) ==16368== by 0x50E6F2: cmd_func (/usr/local/lib/debug/debug-src/obj64/gdb/../../binutils-gdb/gdb/cli/cli-decode.c:1886) The problem originates from the get_current_arch call in py-progspace.c:py_free_pspace. I think the comment in this patch explains things pretty well. Basically, we're in the pspace destructor, and thus there's not much we can rely on. The Python machinery needs an arch, so we give it one, albeit a fiction. I think(!) it doesn't matter. I'm going with this fix because it's not clear to me what The Right fix is, short of removing global state in gdb which is non-trivial. Since "there is always an inferior" calling target_gdbarch seems pretty safe here. 2014-05-19 Doug Evans * python/py-progspace.c (py_free_pspace): Use target_gdbarch instead of get_current_arch. diff --git a/gdb/python/py-progspace.c b/gdb/python/py-progspace.c index cda5a86..c787c69 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. The architecture comes from the inferior, which cannot + be the current one because we wouldn't be deleting its pspace. + We don't need to do much here so this fiction 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;