From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30522 invoked by alias); 26 Oct 2009 21:13:54 -0000 Received: (qmail 30509 invoked by uid 22791); 26 Oct 2009 21:13:53 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 26 Oct 2009 21:13:47 +0000 Received: from int-mx05.intmail.prod.int.phx2.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.18]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n9QLDheJ004017; Mon, 26 Oct 2009 17:13:43 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx05.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n9QLDhsp010547; Mon, 26 Oct 2009 17:13:43 -0400 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n9QLDg8A032220; Mon, 26 Oct 2009 17:13:42 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id EBFE5378113; Mon, 26 Oct 2009 15:13:41 -0600 (MDT) From: Tom Tromey To: Jason Richards Cc: gdb-patches@sourceware.org Subject: Re: infinite loop processing siblings - dwarf2reader - dwarf 3 debug References: <9c25d2960910242124p6dfc4f6an72811d4105711fa2@mail.gmail.com> Reply-To: tromey@redhat.com Date: Mon, 26 Oct 2009 21:13:00 -0000 In-Reply-To: <9c25d2960910242124p6dfc4f6an72811d4105711fa2@mail.gmail.com> (Jason Richards's message of "Sat, 24 Oct 2009 21:24:26 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2009-10/txt/msg00650.txt.bz2 >>>>> "Jason" == Jason Richards writes: Jason> I encountered a problem where GDB gets stuck in an infinite loop Jason> processing dwarf 3 debug information. Turns out the producer has Jason> placed a sibling attribute in a die in a comp unit which Jason> references a previous die in the comp unit. This does not sound like valid DWARF to me. Section 1.9 makes it sound as though the only valid value is the DIE's next sibling. Jason> It seams to me the appropriate fix for this problem is to change Jason> "locate_pdi_sibling" to first return the location past the Jason> children, before returning sibling information, which fixes this Jason> particular problem. Jason> Is there something I am not thinking about? I don't know why the code is the way it is; I assume for performance but I have not looked into it at all. How about also rejecting a DW_AT_sibling that points to an earlier DIE? Tom