public inbox for
help / color / mirror / Atom feed
* gdb and binutils branch master updated. 846060dfd8ec2bf0e78b4049a89b51438bfe0072
@ 2013-11-13  2:44 brobecke
  0 siblings, 0 replies; only message in thread
From: brobecke @ 2013-11-13  2:44 UTC (permalink / raw)
  To: src-cvs

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 -----------------------------------------------------------------;h=846060dfd8ec2bf0e78b4049a89b51438bfe0072

commit 846060dfd8ec2bf0e78b4049a89b51438bfe0072
Author: Joel Brobecker <>
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);
            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.
            * 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(-)

gdb and binutils

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2013-11-13  2:44 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-11-13  2:44 gdb and binutils branch master updated. 846060dfd8ec2bf0e78b4049a89b51438bfe0072 brobecke

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