From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3436 invoked by alias); 15 Oct 2012 18:01:02 -0000 Received: (qmail 3411 invoked by uid 22791); 15 Oct 2012 18:01:01 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_NO X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 15 Oct 2012 18:00:58 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 99B7C1C7DE6; Mon, 15 Oct 2012 14:00:57 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Wk0EA266CWYM; Mon, 15 Oct 2012 14:00:57 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 641451C7CB7; Mon, 15 Oct 2012 14:00:57 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id DA3D1CB492; Mon, 15 Oct 2012 11:00:52 -0700 (PDT) Date: Mon, 15 Oct 2012 18:01:00 -0000 From: Joel Brobecker To: binutils@sourceware.org, gdb-patches@sourceware.org Subject: Re: [RFC/RFA] dangling bfd pointer in archive cache... Message-ID: <20121015180052.GF3050@adacore.com> References: <20121002141405.GD3028@adacore.com> <20121003052937.GB25219@bubble.grove.modra.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="k1lZvvs/B4yU6o8G" Content-Disposition: inline In-Reply-To: <20121003052937.GB25219@bubble.grove.modra.org> User-Agent: Mutt/1.5.21 (2010-09-15) 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 X-SW-Source: 2012-10/txt/msg00226.txt.bz2 --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 706 > No, we should already be calling _bfd_archive_close_and_cleanup via > > > --- a/bfd/opncls.c > > +++ b/bfd/opncls.c > > @@ -719,6 +719,17 @@ bfd_close (bfd *abfd) > > if (! BFD_SEND (abfd, _close_and_cleanup, (abfd))) > > this call. The problem is in coff-rs6000.c (and coff64-rs6000.c) > where the bfd_target vector just uses bfd_true for close_and_cleanup. Attached is a patch that implements your suggestion. Tested on ppc-aix using AdaCore's GDB testsuite. While at it, the powermac XCOFF backend also seemed to be using the same code that eventually leads to the dangling pointer, and so I fixed it as well. It's untested, but seems straightforward enough. OK to commit? Thanks, -- Joel --k1lZvvs/B4yU6o8G Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0001-Dangling-bfd-pointer-in-archive-cache.patch" Content-length: 1158 >From 63169be6cc57b68280afa74944abbfc285e9b0ae Mon Sep 17 00:00:00 2001 From: Joel Brobecker Date: Mon, 15 Oct 2012 19:29:45 +0200 Subject: [PATCH] Dangling bfd pointer in archive cache. This dandling pointer eventually leads to a crash when trying to run on ppc-aix a program using threading... bfd/ChangeLog: * coff-rs6000.c (rs6000coff_vec): Set _close_and_cleanup field to _bfd_archive_close_and_cleanup. (pmac_xcoff_vec): Likewise. --- bfd/coff-rs6000.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/bfd/coff-rs6000.c b/bfd/coff-rs6000.c index edbef95..0945aca 100644 --- a/bfd/coff-rs6000.c +++ b/bfd/coff-rs6000.c @@ -4076,7 +4076,7 @@ const bfd_target rs6000coff_vec = }, /* Generic */ - bfd_true, + _bfd_archive_close_and_cleanup, bfd_true, coff_new_section_hook, _bfd_generic_get_section_contents, @@ -4332,7 +4332,7 @@ const bfd_target pmac_xcoff_vec = }, /* Generic */ - bfd_true, + _bfd_archive_close_and_cleanup, bfd_true, coff_new_section_hook, _bfd_generic_get_section_contents, -- 1.6.5.rc2 --k1lZvvs/B4yU6o8G--