From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23440 invoked by alias); 19 Nov 2013 18:06:23 -0000 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 Received: (qmail 23384 invoked by uid 89); 19 Nov 2013 18:06:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RDNS_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 19 Nov 2013 18:06:21 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rAJI6ERn008016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 19 Nov 2013 13:06:14 -0500 Received: from barimba (ovpn-113-124.phx2.redhat.com [10.3.113.124]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id rAJI6Dwb012295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 19 Nov 2013 13:06:13 -0500 From: Tom Tromey To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 1/2] avoid infinite loop with bad debuginfo References: <1384375873-32160-1-git-send-email-tromey@redhat.com> <1384375873-32160-2-git-send-email-tromey@redhat.com> <52850730.1060109@redhat.com> <87d2lxpo1l.fsf@fleche.redhat.com> <528B7F15.7040605@redhat.com> <87vbzomm78.fsf@fleche.redhat.com> <528B8FF6.7000406@redhat.com> Date: Tue, 19 Nov 2013 19:07:00 -0000 In-Reply-To: <528B8FF6.7000406@redhat.com> (Pedro Alves's message of "Tue, 19 Nov 2013 16:21:10 +0000") Message-ID: <87siusl10r.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-11/txt/msg00558.txt.bz2 >>>>> "Pedro" == Pedro Alves writes: Tom> I can probably find another test case Pedro> Yes, probably by manually creating a corrupted stack. Actually I was thinking of something simpler... Pedro> I think this is an old latent problem. We shouldn't ever have Pedro> two frames with the same id in the frame chain, lots of things Pedro> break otherwise. But somehow, we managed to get this far Pedro> in this particular case. Ok, thanks for this analysis. Pedro> If we can indeed trigger this with a real corruption test Pedro> case, I believe the reason is that the recent-ish addition Pedro> of the frame stash exposes the latent bug: Nice insight. To me this is another internal constraint of the unwinder design that is being violated "somewhere". It seems like we can't really write an ordinary test case for it -- since it is a "shouldn't happen" scenario. Pedro> I still think that such a loop should be broken by never Pedro> having two frames with the same id in the frame chain in the Pedro> first place. This potential infinite loop in value_fetch_lazy Pedro> is really an internal error, IMO. It seems to me that the loop in question could perhaps be reached from some path outside the unwinder. If so, bad DWARF would be able to cause an internal error -- clearly incorrect. I suppose one idea is that the DWARF code should do the checking itself, though. Tom