From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32259 invoked by alias); 17 Oct 2014 14:20:18 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 32250 invoked by uid 89); 17 Oct 2014 14:20:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS 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; Fri, 17 Oct 2014 14:20:17 +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 s9HEK9Ed014024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 17 Oct 2014 10:20:10 -0400 Received: from localhost.localdomain (ovpn-112-31.ams2.redhat.com [10.36.112.31]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9HEK8Zl016122; Fri, 17 Oct 2014 10:20:08 -0400 Message-ID: <54412597.8080600@redhat.com> Date: Fri, 17 Oct 2014 14:20:00 -0000 From: Phil Muldoon MIME-Version: 1.0 To: =?UTF-8?B?w5ZtZXIgU2luYW4gQcSfYWNhbg==?= CC: paul_koning , gdb Subject: Re: recursion limit exceeded in Python API, but there's only one function in traceback References: <543FBDFF.3050709@redhat.com> <104DEFBD-D686-4290-8E3C-725A51C165E6@dell.com> <7BB30632-15BE-4EF8-B84F-D35A27772F18@dell.com> <5440EB39.2060305@redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg00068.txt.bz2 On 17/10/14 11:52, Ömer Sinan Ağacan wrote: > IMO, something like dont_block would be more useful for me. What I would expect > from that argument is that when it's True then `gdb.execute` would return > immediately after GDB starts running the command. > >> A workaround would be to post any gdb.execute statements into the GDB event >> loop. See gdb.post_event. That will return immediately and the gdb.execute >> function will be scheduled to be called in the event loop. Note there is no >> guarantee when this is. But as long as GDB is not busy processing other >> events it usually means right away. > Do you think adding something like `dont_block` would be hard? Maybe I can hack > on that this weekend. Hi, The patch has already been written (I had to fix it for a RH bugzilla entry). I just have not gotten around to posting it upstream yet. I will do that very soon. But if you are interested, the patch is here: https://bugzilla.redhat.com/show_bug.cgi?id=1116957 Cheers Phil