public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Tom Tromey <tromey@redhat.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: Binutils Development <binutils@sourceware.org>
Subject: Re: [PATCH 3/5] remove deleted BFDs from the archive cache
Date: Thu, 16 Aug 2012 18:14:00 -0000	[thread overview]
Message-ID: <87393mpy79.fsf@fleche.redhat.com> (raw)
In-Reply-To: <CAMe9rOoA26=LgVuY9UPkuruAoXYUbBZdWKrEN30kpJE23M41qw@mail.gmail.com>	(H. J. Lu's message of "Thu, 16 Aug 2012 08:57:55 -0700")

HJ> Your checkin destroys binutils:
HJ> http://sourceware.org/bugzilla/show_bug.cgi?id=14475
HJ> Can you fix it?

Sorry about that.  I see now that I will need a more clever plan to
destroy binutils.

I debugged it.  The immediate problem is that
_bfd_compute_and_write_armap calls bfd_free_cached_info
(aka _bfd_free_cached_info).  This then does:

      objalloc_free ((struct objalloc *) abfd->memory);

Whoops, this also frees the areltdata.

So, I have two possible fixes for it.

I've appended the first possible fix.  It changes _bfd_free_cached_info
not to free all the memory attached to the BFD.

A couple notes here.

First, it seems very wrong to me to clear usrdata in this function.  I
didn't touch this; since presumably clients may be relying on this
clearing in a subtle way (if they allocate the usrdata on the BFD
objalloc, which is perhaps the only sensible approach anyhow).  But, I
think that if the appended patch goes in then this line should be
removed in a follow-up.

Second, the check in _bfd_delete_bfd is perhaps ugly.  Maybe
bfd_hash_table_free should do this check instead.  Let me know what you
think.

I rebuilt ld and binutils with this patch.  Additionally, I hacked the
Makefiles to link all the programs with -lmcheck.  Then I ran the ld and
binutils test suites.  There were no regressions.  I also examined one
particular case from ar.exp using valgrind -- I could reproduce the
problem before the patch, but not after.


Another possible fix for this bug would be to allocate the areltdata
using malloc.  That way it would be immune to the objalloc_free call.
This would require a few more tweaks, like properly freeing it in
_bfd_delete_bfd, etc.

I'm happy to make and test this change if you think it would be better.

Tom

2012-08-16  Tom Tromey  <tromey@redhat.com>

	* opncls.c (_bfd_delete_bfd): Check to see if section htab is
	already freed.
	(_bfd_free_cached_info): Don't free the objalloc.

Index: opncls.c
===================================================================
RCS file: /cvs/src/src/bfd/opncls.c,v
retrieving revision 1.72
diff -u -r1.72 opncls.c
--- opncls.c	9 Aug 2012 06:25:53 -0000	1.72
+++ opncls.c	16 Aug 2012 16:57:36 -0000
@@ -132,14 +132,15 @@
 {
   if (abfd->memory)
     {
-      bfd_hash_table_free (&abfd->section_htab);
+      if (abfd->section_htab.memory != NULL)
+	bfd_hash_table_free (&abfd->section_htab);
       objalloc_free ((struct objalloc *) abfd->memory);
     }
 
   free (abfd);
 }
 
-/* Free objalloc memory.  */
+/* Free some information cached in the BFD.  */
 
 bfd_boolean
 _bfd_free_cached_info (bfd *abfd)
@@ -147,14 +148,12 @@
   if (abfd->memory)
     {
       bfd_hash_table_free (&abfd->section_htab);
-      objalloc_free ((struct objalloc *) abfd->memory);
 
       abfd->sections = NULL;
       abfd->section_last = NULL;
       abfd->outsymbols = NULL;
       abfd->tdata.any = NULL;
       abfd->usrdata = NULL;
-      abfd->memory = NULL;
     }
 
   return TRUE;

  reply	other threads:[~2012-08-16 18:11 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-03 14:55 Tom Tromey
2012-08-03 16:12 ` Alan Modra
2012-08-03 20:56   ` Tom Tromey
2012-08-08 22:47   ` Tom Tromey
2012-08-09 10:35     ` Alan Modra
2012-08-15 20:14       ` H.J. Lu
2012-08-15 21:30         ` Tom Tromey
2012-08-16 14:47           ` Alan Modra
2012-08-16 16:31             ` H.J. Lu
2012-08-16 18:14               ` Tom Tromey [this message]
2012-08-16 18:33                 ` H.J. Lu
2012-08-16 18:45                   ` Tom Tromey
2012-08-16 18:49                     ` H.J. Lu
2012-08-16 18:55                       ` Tom Tromey
2012-08-16 20:33                         ` Tom Tromey
2012-08-16 20:38                         ` H.J. Lu
2012-08-16 21:11                 ` H.J. Lu
2012-08-16 21:35                 ` H.J. Lu
2012-08-17  1:01                 ` Alan Modra
2012-08-17  1:06                   ` H.J. Lu
2012-08-17  2:44                     ` Alan Modra
2012-08-17  4:56                       ` Hans-Peter Nilsson
2012-08-17  5:04                         ` Alan Modra
2012-08-17  5:08                         ` H.J. Lu
2012-08-17  5:30                           ` H.J. Lu
2012-08-17  5:42                             ` H.J. Lu
2012-08-17  5:45                               ` H.J. Lu
2012-08-17  6:01                                 ` H.J. Lu
2012-08-17 13:10                                   ` H.J. Lu
2012-08-17 16:50                                     ` Hans-Peter Nilsson
2012-08-17 16:01                           ` Hans-Peter Nilsson
2012-08-17 16:10                             ` H.J. Lu
2012-08-17 16:14                               ` Hans-Peter Nilsson
2012-08-17 16:13                       ` Tom Tromey
2012-08-17 16:26                         ` H.J. Lu
2012-08-17 16:51                           ` Tom Tromey
2012-08-17 17:11                             ` H.J. Lu
2012-08-17 17:22                               ` Tom Tromey
2012-08-17 17:22                                 ` H.J. Lu
2012-08-17 19:03                                   ` Tom Tromey
2012-08-17 19:13                                     ` H.J. Lu
2012-08-18  4:37                         ` Alan Modra
2012-08-21  9:55                           ` Tom Tromey
2012-08-17  1:17                   ` Alan Modra
2012-08-17 15:36                   ` Tom Tromey
2012-08-17 15:38                     ` H.J. Lu
2012-08-17 15:43                       ` Tom Tromey
2012-08-17  0:48           ` H.J. Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87393mpy79.fsf@fleche.redhat.com \
    --to=tromey@redhat.com \
    --cc=binutils@sourceware.org \
    --cc=hjl.tools@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).