From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15983 invoked by alias); 17 Oct 2014 16:41:02 -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 15972 invoked by uid 89); 17 Oct 2014 16:41:01 -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,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-yh0-f51.google.com Received: from mail-yh0-f51.google.com (HELO mail-yh0-f51.google.com) (209.85.213.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 17 Oct 2014 16:41:00 +0000 Received: by mail-yh0-f51.google.com with SMTP id t59so514350yho.24 for ; Fri, 17 Oct 2014 09:40:58 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.66.103 with SMTP id g67mr13051700yhd.61.1413564058217; Fri, 17 Oct 2014 09:40:58 -0700 (PDT) Received: by 10.170.140.214 with HTTP; Fri, 17 Oct 2014 09:40:58 -0700 (PDT) In-Reply-To: References: <543FBDFF.3050709@redhat.com> <104DEFBD-D686-4290-8E3C-725A51C165E6@dell.com> <7BB30632-15BE-4EF8-B84F-D35A27772F18@dell.com> Date: Fri, 17 Oct 2014 16:41:00 -0000 Message-ID: Subject: Re: recursion limit exceeded in Python API, but there's only one function in traceback From: Doug Evans To: =?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?= Cc: paul_koning , pmuldoon , gdb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg00075.txt.bz2 On Fri, Oct 17, 2014 at 2:30 AM, =C3=96mer Sinan A=C4=9Facan wrote: > I'm still having this problem. I just tried this: > > def handler(): > gdb.execute("continue") > print "continue returned" > > This doesn't print anything, until the script fails with "maximum > recursion depth". Then it prints lots of "continue returned" lines. > > So the problem is `gdb.execute` doesn't immediately return and that's > causing Python stack to grow, because GDB is calling this function > without returning anything to previous calls. One thing to keep in mind here is that gdb.execute is akin to typing the command in at the (gdb) prompt. IOW, if you as a user typed "continue" at the (gdb) prompt what would you want to happen? The definition of the "continue" command is that the inferior is resumed until it stops and then the "continue" command completes. > I think I need a version of `gdb.execute` that returns immediately. > ie. async version or something like that. Is such a thing possible? There is "continue &" for the case at hand. There is no async version of gdb.execute itself. Alas there is no corresponding "wait" command for "continue &" (I have one in a sandbox that I get to when I'm able). So once the inferior is running you've kinda lost programmatic control. There is the "interrupt" command but it is broken in the sense that it is implicitly async (the "&" is implicitly present). I have a sandbox that fixes this too (getting this submitted tripped over another gdb bug which I'm needing to fix first - a not uncommon occurrence in gdb-land). Other things come into play here like all-stop vs non-stop https://sourceware.org/gdb/current/onlinedocs/gdb/Thread-Stops.html#Thread-= Stops but the async version of gdb.execute("continue") is gdb.execute("continue &= "). Also note that resuming the inferior in a breakpoint handler is supported, but further commands after the continue are not. This isn't enforced in the python API, so I'm not sure what might happen. Some things may work, others may not. https://sourceware.org/gdb/current/onlinedocs/gdb/Break-Commands.html#Break= -Commands