From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24672 invoked by alias); 17 Oct 2014 14:27:15 -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 24587 invoked by uid 89); 17 Oct 2014 14:27:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wi0-f176.google.com Received: from mail-wi0-f176.google.com (HELO mail-wi0-f176.google.com) (209.85.212.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 17 Oct 2014 14:27:13 +0000 Received: by mail-wi0-f176.google.com with SMTP id hi2so2220655wib.15 for ; Fri, 17 Oct 2014 07:27:10 -0700 (PDT) X-Received: by 10.180.189.11 with SMTP id ge11mr14141523wic.4.1413556030499; Fri, 17 Oct 2014 07:27:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.106.68 with HTTP; Fri, 17 Oct 2014 07:26:30 -0700 (PDT) In-Reply-To: <54412597.8080600@redhat.com> References: <543FBDFF.3050709@redhat.com> <104DEFBD-D686-4290-8E3C-725A51C165E6@dell.com> <7BB30632-15BE-4EF8-B84F-D35A27772F18@dell.com> <5440EB39.2060305@redhat.com> <54412597.8080600@redhat.com> From: =?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?= Date: Fri, 17 Oct 2014 14:27:00 -0000 Message-ID: Subject: Re: recursion limit exceeded in Python API, but there's only one function in traceback To: Phil Muldoon Cc: paul_koning , gdb Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg00069.txt.bz2 > 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 Can anyone explain me how does GIL related with my problem? A blocking call will still be blocking no matter what happens to GIL, I don't understand how `gdb.execute("continue")` won't fill the stack with free GIL.