From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22489 invoked by alias); 25 Oct 2009 04:24:35 -0000 Received: (qmail 21893 invoked by uid 22791); 25 Oct 2009 04:24:32 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-gx0-f212.google.com (HELO mail-gx0-f212.google.com) (209.85.217.212) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 25 Oct 2009 04:24:28 +0000 Received: by gxk4 with SMTP id 4so10975238gxk.8 for ; Sat, 24 Oct 2009 21:24:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.109.11 with SMTP id l11mr2831898anm.145.1256444666797; Sat, 24 Oct 2009 21:24:26 -0700 (PDT) Date: Sun, 25 Oct 2009 04:24:00 -0000 Message-ID: <9c25d2960910242124p6dfc4f6an72811d4105711fa2@mail.gmail.com> Subject: infinite loop processing siblings - dwarf2reader - dwarf 3 debug From: Jason Richards To: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 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/msg00620.txt.bz2 I encountered a problem where GDB gets stuck in an infinite loop processing dwarf 3 debug information. Turns out the producer has placed a sibling attribute in a die in a comp unit which references a previous die in the comp unit. "locate_pdi_sibling" first checks for the presence of this sibling and returns it instead of scanning forward past the children (there are children present in this die). It seams to me the appropriate fix for this problem is to change "locate_pdi_sibling" to first return the location past the children, before returning sibling information, which fixes this particular problem. Is there something I am not thinking about? Regards- Jason Richards