From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27893 invoked by alias); 30 Apr 2014 10:55:52 -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 27873 invoked by uid 89); 30 Apr 2014 10:55:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail-gw3-out.broadcom.com Received: from mail-gw3-out.broadcom.com (HELO mail-gw3-out.broadcom.com) (216.31.210.64) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 30 Apr 2014 10:55:50 +0000 Received: from irvexchcas07.broadcom.com (HELO IRVEXCHCAS07.corp.ad.broadcom.com) ([10.9.208.55]) by mail-gw3-out.broadcom.com with ESMTP; 30 Apr 2014 04:16:06 -0700 Received: from IRVEXCHSMTP2.corp.ad.broadcom.com (10.9.207.52) by IRVEXCHCAS07.corp.ad.broadcom.com (10.9.208.55) with Microsoft SMTP Server (TLS) id 14.3.174.1; Wed, 30 Apr 2014 03:55:48 -0700 Received: from mail-irva-13.broadcom.com (10.10.10.20) by IRVEXCHSMTP2.corp.ad.broadcom.com (10.9.207.52) with Microsoft SMTP Server id 14.3.174.1; Wed, 30 Apr 2014 03:55:49 -0700 Received: from xl-cam-21.broadcom.com (xl-cam-21.cam.broadcom.com [10.177.132.81]) by mail-irva-13.broadcom.com (Postfix) with ESMTP id E2FBA51E7D; Wed, 30 Apr 2014 03:55:48 -0700 (PDT) Received: by xl-cam-21.broadcom.com (Postfix, from userid 15136) id 3EADC2CE899E; Wed, 30 Apr 2014 11:55:48 +0100 (BST) From: Andrew Burgess To: CC: Andrew Burgess Subject: [PATCH v3 0/4] Catch errors in get_prev_frame. Date: Wed, 30 Apr 2014 10:55:00 -0000 Message-ID: <1398855344-25278-1-git-send-email-aburgess@broadcom.com> In-Reply-To: <533EC5B7.6080600@broadcom.com> References: <533EC5B7.6080600@broadcom.com> MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2014-04/txt/msg00634.txt.bz2 This V3 patch completely replaces the previous patch posted here: https://sourceware.org/ml/gdb-patches/2014-04/msg00064.html Which due to a series of blunders is pretty much unreviewable. The content of this series is identical to the previous attempts but the patches should be correctly formatted, and the email text description is included too. Patch Description: While working on a reproducer for this patch: https://sourceware.org/ml/gdb-patches/2014-03/msg00629.html I ran into a few other issues. The route cause of the problems I'm seeing is that not all errors thrown within get_prev_frame are caught. This causes a couple of problems, 1. For the MI this means that commands like -stack-info-depth will return an error rather than a result. Even more annoying, is that depending on where in the process the error is thrown enough state may be left set that the /next/ time -stack-info-depth is asked, the correct result is given! 2. For standard CLI backtraces our the results are (I think) inconsistent, so for example some backtraces will end with a message like: "Backtrace stopped: previous frame inner to this frame (corrupted stack?)", this message will be displayed every time the backtrace is requested, in other cases though, the reason is only displayed the first time a backtrace is requested, this is the case when an uncaught error causes the backtrace to stop, also in the uncaught error case the "Backtrace stopped" prefix does not appear. This patch set tries to fix both these issues by holding a frame specific string that describes why the backtrace stopped at this frame (only for the last frame in the backtrace obviously). If this string is not set then we still use the existing generic strings. A new TRY_CATCH inside get_prev_frame catches (currently) all unhandled errors, the error message from these errors is then used as a frame specific stop reason string. There's a new unwind_stop_reason code for this case, UNWIND_MISC_ERROR. If it's felt that catching all errors like this is too much then I could soften this to just catching MEMORY_ERRORs, as right now the problems I'm seeing all relate to accessing memory through a corrupted stack pointer. Thanks, Andrew Andrew Burgess (4): New test for backtrace when the stack pointer is invalid (inaccessible). Remove previous frame if an error occurs when computing frame id during unwind. Deprecate frame_stop_reason_string. Add a TRY_CATCH to get_prev_frame to better handle errors during unwind. gdb/frame.c | 123 +- gdb/frame.h | 11 +- gdb/guile/scm-frame.c | 2 +- gdb/python/py-frame.c | 2 +- gdb/stack.c | 4 +- .../gdb.arch/amd64-invalid-stack-middle.S | 1410 ++++++++++++++++++++ .../gdb.arch/amd64-invalid-stack-middle.c | 89 ++ .../gdb.arch/amd64-invalid-stack-middle.exp | 78 ++ gdb/testsuite/gdb.arch/amd64-invalid-stack-top.c | 73 + gdb/testsuite/gdb.arch/amd64-invalid-stack-top.exp | 81 ++ gdb/unwind_stop_reasons.def | 5 +- 11 files changed, 1850 insertions(+), 28 deletions(-) create mode 100644 gdb/testsuite/gdb.arch/amd64-invalid-stack-middle.S create mode 100644 gdb/testsuite/gdb.arch/amd64-invalid-stack-middle.c create mode 100644 gdb/testsuite/gdb.arch/amd64-invalid-stack-middle.exp create mode 100644 gdb/testsuite/gdb.arch/amd64-invalid-stack-top.c create mode 100644 gdb/testsuite/gdb.arch/amd64-invalid-stack-top.exp -- 1.8.1.3