From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30317 invoked by alias); 13 Nov 2013 02:44:38 -0000 Mailing-List: contact src-cvs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: src-cvs-owner@sourceware.org Received: (qmail 30293 invoked by uid 9190); 13 Nov 2013 02:44:37 -0000 Date: Wed, 13 Nov 2013 02:44:00 -0000 Message-ID: <20131113024434.30268.qmail@sourceware.org> From: brobecke@sourceware.org To: src-cvs@sourceware.org Subject: gdb and binutils branch master updated. 846060dfd8ec2bf0e78b4049a89b51438bfe0072 X-Git-Refname: refs/heads/master X-Git-Reftype: branch X-Git-Oldrev: 7d4df6a4e13f9f15c26ac132775d7ab570b38456 X-Git-Newrev: 846060dfd8ec2bf0e78b4049a89b51438bfe0072 X-SW-Source: 2013-q4/txt/msg00126.txt.bz2 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 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