public inbox for src-cvs@sourceware.org
help / color / mirror / Atom feed
From: brobecke@sourceware.org
To: src-cvs@sourceware.org
Subject: gdb and binutils branch master updated. 846060dfd8ec2bf0e78b4049a89b51438bfe0072
Date: Wed, 13 Nov 2013 02:44:00 -0000	[thread overview]
Message-ID: <20131113024434.30268.qmail@sourceware.org> (raw)

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".

The branch, master has been updated
       via  846060dfd8ec2bf0e78b4049a89b51438bfe0072 (commit)
      from  7d4df6a4e13f9f15c26ac132775d7ab570b38456 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=846060dfd8ec2bf0e78b4049a89b51438bfe0072

commit 846060dfd8ec2bf0e78b4049a89b51438bfe0072
Author: Joel Brobecker <brobecker@adacore.com>
Date:   Tue Nov 5 07:01:45 2013 -0500

    crash while re-reading symbols from objfile on ppc-aix.
    
    This patch aims at fixing the following problem, where the user:
    
      . debugs its program
      . makes a modification and rebuilds it *without exiting the debugger*
      . returns to its debugging session and restarts the inferior
    
    In that situation, the debugger notices that the underlying executable
    has changed and that re-reading its symbols is needed. Shortly after
    displaying a message informing the user of the situation, GDB crashes:
    
       (gdb) run
       [...]
       `/[...]/dest' has changed; re-reading symbols.
       zsh: 13434922 segmentation fault (core dumped)
    
    The crash occurs while trying to allocate some memory on the bfd_bfd
    obstack.  But, at some point in time, the whole obstack data gets
    corrupted, nullified. So the memory allocation fails trying to call
    a function at a NULL address. (side note: when debugging GDB in GDB,
    top-gdb reports a SIGILL, while the shell makes it look like it was
    a SIGSEGV - the discrepancy is not critical to the investigation
    and therefore was not explored)
    
    The corruption occurred because the region where the per_bfd data
    got free'ed nearly after it got allocated! This is what happens,
    in chronological order (see reread_symbols):
    
      1. GDB notices that the executable has changed, decides to
         re-read its symbols.
    
      2. Opens a new bfd, unrefs the old one
    
      3. Calls set_objfile_per_bfd (objfile);
    
      4. Re-initializes the objfile's obstack:
         obstack_init (&objfile->objfile_obstack);
    
    I think that the normal behavior for set_objfile_per_bfd would
    be to search for already-allocated shared per_bfd data, and
    allocate new one if not found.  The critical difference between
    a platform such as x86_64-linuxe where it works, and ppc-aix,
    where it doesn't lies in the fact that bfd-data sharing is not
    activated on ppc-aix, and as a result, the per-bfd data gets
    allocated on the objfile's obstack instead of in the bfd objalloc:
    
          /* If the object requires gdb to do relocations, we simply fall
             back to not sharing data across users.  These cases are rare
             enough that this seems reasonable.  */
          if (abfd != NULL && !gdb_bfd_requires_relocations (abfd))
            {
              storage = bfd_zalloc (abfd, sizeof (struct objfile_per_bfd_storage));
              set_bfd_data (abfd, objfiles_bfd_data, storage);
            }
          else
            storage = OBSTACK_ZALLOC (&objfile->objfile_obstack,
                                      struct objfile_per_bfd_storage);
    
    Allocating that per_bfd storage is of course nearly useless since
    we end up free-ing right after in step (4) above. Eventually,
    the memory region ends up being re-used, hence the corruption
    leading to the crash.
    
    This fix was simply to move the call to set_objfile_per_bfd after
    the objfile's obstack re-initialization.
    
    gdb/ChangeLog:
    
            * symfile.c (reread_symbols): Move call to set_objfile_per_bfd
            after re-initialization of OBJFILE's obstack.

-----------------------------------------------------------------------

Summary of changes:
 gdb/ChangeLog |    5 +++++
 gdb/symfile.c |    8 ++++++--
 2 files changed, 11 insertions(+), 2 deletions(-)


hooks/post-receive
-- 
gdb and binutils


                 reply	other threads:[~2013-11-13  2:44 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20131113024434.30268.qmail@sourceware.org \
    --to=brobecke@sourceware.org \
    --cc=src-cvs@sourceware.org \
    /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).