From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17265 invoked by alias); 3 Nov 2011 17:05:58 -0000 Received: (qmail 17256 invoked by uid 22791); 3 Nov 2011 17:05:57 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from caibbdcaaaaf.dreamhost.com (HELO homiemail-a81.g.dreamhost.com) (208.113.200.5) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 03 Nov 2011 17:05:39 +0000 Received: from homiemail-a81.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a81.g.dreamhost.com (Postfix) with ESMTP id C0919A8074; Thu, 3 Nov 2011 10:05:36 -0700 (PDT) Received: from redwood.eagercon.com (c-76-102-3-160.hsd1.ca.comcast.net [76.102.3.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: eager@eagerm.com) by homiemail-a81.g.dreamhost.com (Postfix) with ESMTPSA id 3A8BAA8071; Thu, 3 Nov 2011 10:05:35 -0700 (PDT) Message-ID: <4EB2C9DD.4030305@eagerm.com> Date: Thu, 03 Nov 2011 17:05:00 -0000 From: Michael Eager User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110927 Thunderbird/7.0 MIME-Version: 1.0 To: Jan Kratochvil CC: "gdb-patches@sourceware.org" Subject: Re: SEGV in dwarf2read.c -- gdb-7.2 References: <4EB2BD58.3080003@eagerm.com> <20111103162026.GA12269@host1.jankratochvil.net> In-Reply-To: <20111103162026.GA12269@host1.jankratochvil.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-11/txt/msg00082.txt.bz2 On 11/03/2011 09:20 AM, Jan Kratochvil wrote: > Hello Michael, > > sorry but I cannot comment more without a reproducer, such possible fix should > have a regression testcase anyway. Could you provide a reproducer in some > form even just off-list (so that I can reduce it if it is not completely > public and not so critically secure)? I don't think I can. The application is proprietary. I not sure that I can create an artificial test case with a structure containing hundreds of members and multiple compilation units which might trigger the SEGV. > On Thu, 03 Nov 2011 17:12:08 +0100, Michael Eager wrote: >> I ran into a SEGV in in gdb-7.2 > > The stable release is 7.3.1, moreover for such development I would find only > FSF GDB HEAD relevant. I remember several fixes which it may be related to. Can't help that. Bugs are found on the tools in use, not necessarily the latest release. >> Is there a reason to read the CU header into a temporary data >> area rather than reload it using load_full_comp_unit() which will add it to >> the CU cache? > > I guess for performance reasons, the CU header read-in vs. load_full_comp_unit > is a big difference. There are already some PRs (such as 12828 (a)) where GDB > needlessly expands too many CUs "locking itself" by inacceptable performance. It seems that this would cause the CU header to be read many times, when it would otherwise use the cache. -- Michael Eager eager@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077