From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6413 invoked by alias); 13 Nov 2013 20:51:29 -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 6398 invoked by uid 89); 13 Nov 2013 20:51:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 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; Wed, 13 Nov 2013 20:51:27 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rADKpJkv012992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 13 Nov 2013 15:51:20 -0500 Received: from barimba.redhat.com (ovpn-113-124.phx2.redhat.com [10.3.113.124]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rADKpIO0026495; Wed, 13 Nov 2013 15:51:19 -0500 From: Tom Tromey To: gdb-patches@sourceware.org Cc: Tom Tromey Subject: [PATCH 1/2] avoid infinite loop with bad debuginfo Date: Wed, 13 Nov 2013 22:03:00 -0000 Message-Id: <1384375873-32160-2-git-send-email-tromey@redhat.com> In-Reply-To: <1384375873-32160-1-git-send-email-tromey@redhat.com> References: <1384375873-32160-1-git-send-email-tromey@redhat.com> X-SW-Source: 2013-11/txt/msg00358.txt.bz2 The immediate failure in PR 16155 is an infinite loop in value_fetch_lazy. Each iteration of the loop inside the lval_register branch computes a value with the same frame id and same register number as the previous iteration. It never makes progress, using progressively more memory creating new values. It seems to me that it never makes sense to let this loop run indefinitely. This patch adds a check and throws an exception if the same register is returned. I intentionally did not use an internal error, because this situation can be caused by bad debuginfo. I did not go the full distance and have the code check all previous values. I could do that if folks want. With this patch at least the infinite loop is gone. Now the test case yields: (gdb) bt #0 0x0000007fb7ed485c in nanosleep () from /lib64/libc.so.6 #1 0x0000007fb7ed4508 in sleep () from /lib64/libc.so.6 #2 0x00000000004008bc in thread_function (arg=0x4) at threadapply.c:73 #3 0x0000007fb7fad950 in start_thread () from /lib64/libpthread.so.0 #4 0x0000007fb7f0956c in clone () from /lib64/libc.so.6 #5 0x0000007fb7f0956c in clone () from /lib64/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) 2013-11-13 Tom Tromey PR backtrace/16155: * value.c (value_fetch_lazy): Throw exception if get_frame_register_value returns the same register. --- gdb/ChangeLog | 6 ++++++ gdb/value.c | 9 ++++++++- 2 files changed, 14 insertions(+), 1 deletion(-) diff --git a/gdb/value.c b/gdb/value.c index 1f562f5..f8831ae 100644 --- a/gdb/value.c +++ b/gdb/value.c @@ -3507,7 +3507,9 @@ value_fetch_lazy (struct value *val) while (VALUE_LVAL (new_val) == lval_register && value_lazy (new_val)) { - frame = frame_find_by_id (VALUE_FRAME_ID (new_val)); + struct frame_id last_frame_id = VALUE_FRAME_ID (new_val); + + frame = frame_find_by_id (last_frame_id); regnum = VALUE_REGNUM (new_val); gdb_assert (frame != NULL); @@ -3521,6 +3523,11 @@ value_fetch_lazy (struct value *val) regnum, type)); new_val = get_frame_register_value (frame, regnum); + if (VALUE_LVAL (new_val) == lval_register + && value_lazy (new_val) + && frame_id_eq (VALUE_FRAME_ID (new_val), last_frame_id)) + error (_("infinite loop while fetching a register; " + "probably bad debug info")); } /* If it's still lazy (for instance, a saved register on the -- 1.8.1.4