From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24212 invoked by alias); 7 Feb 2015 14:45:06 -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 24196 invoked by uid 89); 7 Feb 2015 14:45:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Sat, 07 Feb 2015 14:45:04 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t17Ej3tB009574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Sat, 7 Feb 2015 09:45:03 -0500 Received: from host1.jankratochvil.net (ovpn-116-113.ams2.redhat.com [10.36.116.113]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t17Ej2Wi019721; Sat, 7 Feb 2015 09:45:02 -0500 Subject: [PATCH 0/6] framefilter quit: PR cli/17716 From: Jan Kratochvil To: gdb-patches@sourceware.org Cc: Phil Muldoon Date: Sat, 07 Feb 2015 14:45:00 -0000 Message-ID: <20150207144501.14897.90709.stgit@host1.jankratochvil.net> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-02/txt/msg00168.txt.bz2 Hi Phil, as I have seen gdb-7.9 may get released with this annoying bug I have attempted a fix. It is far from complete but it should hopefully handle most of the uninterruptable cases - although some of them will apparently still remain there. Primarily I do not understand intentions of the code: gdbpy_convert_exception() is required in code called from Python, such as for bpfinishpy_init() as one of many examples. But if I haven't make mistake I do not see any of the GDB functions changed in this patchset (py_print_single_arg, enumerate_locals, py_print_frame) would be called by Python. Therefore I do not see why they should call gdbpy_convert_exception() at all (moreover they call it so many times). These functions are normally called by GDB and GDB is GDB exception safe so GDB exceptions can be safely thrown. Not all of the gdb/python/ code was GDB exception safe, this is why I had to change for example also gdbpy_apply_frame_filter(). I find more safe to write code as exception safe in general. Hopefully I did not forget to make exception safe any of the possible callers of the involved functions. Then I do not understand why there is EXT_LANG_BT_ERROR. GDB has exceptions so it does not need error return values. Error return values can be used in cases when it is more simple for the code (As current implementation of GDB exceptions is needlessly complicated to use) - when callee detects a problem on its own. But if caller has to TRY_CATCH exceptions from futher callees and convert them into EXT_LANG_BT_ERROR so that its caller can check for EXT_LANG_BT_ERROR... Why hasn't the caller just do TRY_CATCH on its own? I haven't tried to remove EXT_LANG_BT_ERROR at all myself in this patchset, though. That would be larger work. As I said the patch is not complete but I believe the direction of this patch is correct and futher fixes can extend it. Jan