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