From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9616 invoked by alias); 28 Sep 2011 20:41:17 -0000 Received: (qmail 9607 invoked by uid 22791); 28 Sep 2011 20:41:16 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org Received: from qmta12.westchester.pa.mail.comcast.net (HELO qmta12.westchester.pa.mail.comcast.net) (76.96.59.227) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 28 Sep 2011 20:41:02 +0000 Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta12.westchester.pa.mail.comcast.net with comcast id eLSh1h0030QuhwU5CLh3F3; Wed, 28 Sep 2011 20:41:03 +0000 Received: from [10.127.238.91] ([65.206.2.68]) by omta02.westchester.pa.mail.comcast.net with comcast id eLgr1h00u1U2a2h3NLguqD; Wed, 28 Sep 2011 20:41:00 +0000 Subject: Re: Python: fetch value when building gdb.Value object Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Koning In-Reply-To: Date: Wed, 28 Sep 2011 20:42:00 -0000 Cc: gdb-patches@sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <36B29E9D-F2B3-446F-AF8A-97254A3AAEE2@comcast.net> To: pmuldoon@redhat.com 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: 2011-09/txt/msg00477.txt.bz2 On Sep 28, 2011, at 3:24 PM, Phil Muldoon wrote: > Paul Koning writes: >=20 >> ... >> Index: python/py-value.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> RCS file: /cvs/src/src/gdb/python/py-value.c,v >> retrieving revision 1.25 >> diff -u -r1.25 py-value.c >> --- python/py-value.c 27 Jun 2011 19:21:51 -0000 1.25 >> +++ python/py-value.c 21 Sep 2011 15:45:12 -0000 >> ... >=20 >> @@ -1045,7 +1045,15 @@ >> value_to_value_object (struct value *val) >> { >> value_object *val_obj; >> + volatile struct gdb_exception except; >>=20 >> + TRY_CATCH (except, RETURN_MASK_ALL) >> + { >=20 > Something that Jan pointed out a few weeks ago, is our exception net is > too wide, and asked me to review usage of REVIEW_MASK_ALL. In this > case, this should probably be RETURN_MASK_ERROR.=20 Question on that... If I use RETURN_MASK_ERROR and control/C is hit, does that mean the current= ly running code aborts and the outer handler that does have RETURN_MASK_ALL= is entered? If so, most of the Python code seems to be a candidate for RETURN_MASK_ERRO= R. One exception is valpy_getitem (in py-value.c) since it has an xfree(va= lue) after the TRY_CATCH but before the GDB_PY_HANDLE_EXCEPTION (outside th= e TRY_CATCH block, though -- is that right?) Probably related: I just tried an infinite Python loop and found that contr= ol-C had no effect. I wonder if the Python interpreter is setting up its o= wn control-C trap (quite possibly -- that's a Python exception after all) a= nd we're losing it somewhere along the lines. paul