From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Newsgroups: gmane.lisp.guile.bugs Subject: bug#59021: Unbounded heap growth when combining dynamic states & delimited continuation Date: Sat, 05 Nov 2022 23:04:22 +0100 Message-ID: <877d09hxcp.fsf@gnu.org> References: <87h6zelgr1.fsf@inria.fr> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4605"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) Cc: Andy Wingo To: 59021@debbugs.gnu.org Original-X-From: bug-guile-bounces+guile-bugs=m.gmane-mx.org@gnu.org Sat Nov 05 23:05:14 2022 Return-path: Envelope-to: guile-bugs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1orRHt-00012D-6G for guile-bugs@m.gmane-mx.org; Sat, 05 Nov 2022 23:05:13 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1orRHj-0005WW-8R; Sat, 05 Nov 2022 18:05:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1orRHi-0005WJ-Es for bug-guile@gnu.org; Sat, 05 Nov 2022 18:05:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1orRHi-0004iy-6F for bug-guile@gnu.org; Sat, 05 Nov 2022 18:05:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1orRHh-0003XK-Vg for bug-guile@gnu.org; Sat, 05 Nov 2022 18:05:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Sat, 05 Nov 2022 22:05:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59021 X-GNU-PR-Package: guile Original-Received: via spool by 59021-submit@debbugs.gnu.org id=B59021.166768588513562 (code B ref 59021); Sat, 05 Nov 2022 22:05:01 +0000 Original-Received: (at 59021) by debbugs.gnu.org; 5 Nov 2022 22:04:45 +0000 Original-Received: from localhost ([127.0.0.1]:58235 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1orRHQ-0003Wf-1w for submit@debbugs.gnu.org; Sat, 05 Nov 2022 18:04:45 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:47936) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1orRHC-0003WD-K6 for 59021@debbugs.gnu.org; Sat, 05 Nov 2022 18:04:43 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1orRH7-0004go-DF; Sat, 05 Nov 2022 18:04:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To: From; bh=l/c7uUJIzrVmaAkMxTnAPdYS+QzqhNnhhWMkm9UqvJA=; b=WP2augYjev7sXpavaSg3 F9TWR9zJ5tApiPrqb9ynnlQ+MQUB5PZNiUqQd4PM09UiRx6u7sXTr61n1FXsZo0nxya3GP6jaFCUE qV1Z9AInT/gReUaWHRT1xW8f56kxBT0ohXWRk3bnKFuqyy6gvb3x2EK2IvAbq9BT2eMZAOx8+A8FP N0wbC4rQ/FZ3C7GqufQpB4Zl3/F67c1sNmPyXmLhyTDl/zH28mJfX5NDrezNBZRHgYaWHeU3An9ph 41/llTSNi1vy644+DDq+C15vtUhk3fK1gscx8Og05q5jPiSN4jSDo6Dhfu+XWCqX3gCuvAQTIMX1Q q2LmK/svIbhUyw==; Original-Received: from 91-160-117-201.subs.proxad.net ([91.160.117.201] helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1orRH6-00045n-Tz; Sat, 05 Nov 2022 18:04:25 -0400 In-Reply-To: <87h6zelgr1.fsf@inria.fr> ("Ludovic =?UTF-8?Q?Court=C3=A8s?="'s message of "Fri, 04 Nov 2022 19:24:50 +0100") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: "bug-guile" Errors-To: bug-guile-bounces+guile-bugs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.bugs:10412 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ludovic Court=C3=A8s skribis: > Consider this code: > > ;; https://issues.guix.gnu.org/58631 > ;; https://github.com/wingo/fibers/issues/65 > > (define loss > (make-vector 1000000)) > > (let ((tag (make-prompt-tag "my prompt"))) > (define handler > (lambda (k i) > (when (zero? (modulo i 2000000)) > (pk 'heap-size (assoc-ref (gc-stats) 'heap-size))) > > (call-with-prompt tag > (lambda () > (k (modulo (+ 1 i) 10000000))) > handler))) > > (call-with-prompt tag > (let ((state (current-dynamic-state))) > (lambda () > ;; (define (with-dynamic-state state thunk) > ;; (let ((previous #f)) > ;; (dynamic-wind > ;; (lambda () (set! previous (set-current-dynamic-state sta= te))) > ;; thunk > ;; (lambda () (set-current-dynamic-state previous))))) > (with-dynamic-state state > (lambda () > (let loop ((i 0)) > (loop (abort-to-prompt tag i))))))) > handler)) > > On Guile 3.0.8, this program exhibits seemingly unbounded heap growth. This is fixed by the patch below (tested against the test case above and the Fibers and Shepherd test cases mentioned before): --=-=-= Content-Type: text/x-patch Content-Disposition: inline diff --git a/libguile/vm.c b/libguile/vm.c index 6fd5c554f..516bae773 100644 --- a/libguile/vm.c +++ b/libguile/vm.c @@ -165,11 +165,13 @@ capture_stack (union scm_vm_stack_element *stack_top, scm_t_dynstack *dynstack, uint32_t flags) { struct scm_vm_cont *p; + size_t stack_size; - p = scm_gc_malloc (sizeof (*p), "capture_vm_cont"); - p->stack_size = stack_top - sp; - p->stack_bottom = scm_gc_malloc (p->stack_size * sizeof (*p->stack_bottom), - "capture_vm_cont"); + stack_size = stack_top - sp; + p = scm_gc_malloc (sizeof (*p) + stack_size * sizeof (*p->stack_bottom), + "capture_vm_cont"); + p->stack_size = stack_size; + p->stack_bottom = (void *) ((char *) p + sizeof (*p)); p->vra = vra; p->mra = mra; p->fp_offset = stack_top - fp; --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Using a simple heap profiler (more on that later), I noticed that the stacks allocated at =E2=80=98p->stack_bottom=E2=80=99 would be partly retai= ned, explaining the heap growth. I couldn=E2=80=99t pinpoint what exactly is keeping a pointer to the stack,= but what I can tell is that the trick above makes that impossible (because we disable interior pointer tracing), hence the difference. Also, why changing the SCM_DYNSTACK_TYPE_DYNAMIC_STATE entry to an SCM_DYNSTACK_TYPE_UNWINDER entry would make a difference remains a mystery to me. I=E2=80=99m interested in theories that would explain all this in more deta= il! I=E2=80=99ll go ahead with the fix above if there are no objections. It=E2=80=99s not fully satisfying but still it=E2=80=99s a relief. Ludo=E2=80=99. --=-=-=--