From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21338 invoked by alias); 7 Feb 2008 20:18:02 -0000 Received: (qmail 21323 invoked by uid 71); 7 Feb 2008 20:18:01 -0000 Date: Thu, 07 Feb 2008 20:18:00 -0000 Message-ID: <20080207201801.21322.qmail@sourceware.org> To: nobody@sources.redhat.com Cc: gdb-prs@sources.redhat.com, From: Greg Law Subject: Re: c++/2412: gdb crashes with complex data Reply-To: Greg Law Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org X-SW-Source: 2008-q1/txt/msg00034.txt.bz2 The following reply was made to PR c++/2412; it has been noted by GNATS. From: Greg Law To: jacob@jacob.remcomp.fr Cc: gdb-gnats@sources.redhat.com Subject: Re: c++/2412: gdb crashes with complex data Date: Thu, 07 Feb 2008 20:12:10 +0000 This is a multi-part message in MIME format. --------------010303040502090909070606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit This sounds like it could be the same issue that I reported (and supplied a patch for) a few days ago. Jacob - could you try with the attached patch applied and see if it solves your problem? Cheers, Greg jacob@jacob.remcomp.fr wrote: >> Number: 2412 >> Category: c++ >> Synopsis: gdb crashes with complex data >> Confidential: no >> Severity: critical >> Priority: high >> Responsible: unassigned >> State: open >> Class: sw-bug >> Submitter-Id: net >> Arrival-Date: Wed Feb 06 23:38:01 UTC 2008 >> Closed-Date: >> Last-Modified: >> Originator: Jacob Navia >> Release: GNU gdb 6.7.1 >> Organization: >> Environment: > linux >> Description: > Every time I want to display a complex number in gdb > it crashes. > > Crash in > void > print_floating (const gdb_byte *valaddr, struct type *type, > struct ui_file *stream) > > How to reproduce > > 1) Define a long double _Complex number. > For example: long double _Complex foo = 4.8; > 3) In gdb type > print foo > > crash, gdb dies. > > This is after I downloaded the latest version. > > Machine: > > i486 linux vanilla ubuntu distribution. > root@ubuntu:/tmp/gdb-6.7.1/gdb# gcc -v > Utilisation des specs internes. > Target: i486-linux-gnu > Configuré avec: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr --with-gxx-include-dir=/usr/include/c++/4.0.2 --enable-shared --with-system-zlib --libexecdir=/usr/lib --enable-nls --without-included-gettext --enable-threads=posix --program-suffix=-4.0 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2 .0/jre --enable-mpfr --disable-werror --enable-checking=release i486-linux-gnu > Modèle de thread: posix > version gcc 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9) > > root@ubuntu:/tmp/gdb-6.7.1/gdb# gdb -v > GNU gdb 6.7.1 > Copyright (C) 2007 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "i686-pc-linux-gnu". >> How-To-Repeat: > 1) Define a long double _Complex number. > For example: long double _Complex foo = 4.8; > 2) In gdb type > print foo > > crash, gdb dies. >> Fix: > >> Release-Note: >> Audit-Trail: >> Unformatted: -- Greg Law, Undo Software http://undo-software.com/ --------------010303040502090909070606 Content-Type: text/x-patch; name="regcache_fix.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="regcache_fix.patch" Index: gdb/regcache.c =================================================================== RCS file: /cvs/src/src/gdb/regcache.c,v retrieving revision 1.163 diff -u -r1.163 regcache.c --- gdb/regcache.c 1 Jan 2008 22:53:12 -0000 1.163 +++ gdb/regcache.c 4 Feb 2008 22:24:32 -0000 @@ -472,6 +472,9 @@ regcache_xfree (current_regcache); current_regcache = NULL; + /* Need to forget about any frames we have cached, too. */ + reinit_frame_cache (); + /* Force cleanup of any alloca areas if using C alloca instead of a builtin alloca. This particular call is used to clean up areas allocated by low level target code which may build up --------------010303040502090909070606--