From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Newsgroups: gmane.emacs.bugs Subject: bug#59029: 29.0.50; noverlay: pdumper.c: dump_interval_node recursion has no base case Date: Sat, 05 Nov 2022 06:41:41 +0100 Message-ID: References: <87leoqwc4o.fsf@rfc20.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37624"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 59029@debbugs.gnu.org, stefan monnier To: Matt Armstrong Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Nov 05 06:42:31 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1orBwt-0009bP-Kf for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 05 Nov 2022 06:42:31 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1orBwW-0007CI-PU; Sat, 05 Nov 2022 01:42:08 -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 1orBwQ-0007Bp-Ve for bug-gnu-emacs@gnu.org; Sat, 05 Nov 2022 01:42:07 -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 1orBwQ-0005CY-Mx for bug-gnu-emacs@gnu.org; Sat, 05 Nov 2022 01:42:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1orBwQ-0003ut-A9 for bug-gnu-emacs@gnu.org; Sat, 05 Nov 2022 01:42:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Nov 2022 05:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59029 X-GNU-PR-Package: emacs Original-Received: via spool by 59029-submit@debbugs.gnu.org id=B59029.166762691315034 (code B ref 59029); Sat, 05 Nov 2022 05:42:02 +0000 Original-Received: (at 59029) by debbugs.gnu.org; 5 Nov 2022 05:41:53 +0000 Original-Received: from localhost ([127.0.0.1]:55313 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1orBwG-0003uN-LT for submit@debbugs.gnu.org; Sat, 05 Nov 2022 01:41:53 -0400 Original-Received: from mail-ed1-f48.google.com ([209.85.208.48]:39462) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1orBwD-0003u2-18 for 59029@debbugs.gnu.org; Sat, 05 Nov 2022 01:41:50 -0400 Original-Received: by mail-ed1-f48.google.com with SMTP id f7so10350645edc.6 for <59029@debbugs.gnu.org>; Fri, 04 Nov 2022 22:41:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=JLx5uQU6POKTXM1+DX38rzmmgN8lknzYRrgfAACpD/o=; b=EOOsKX5hyIjYCIJI8yfb88jmklgEIfgScvm7aoG7BKjlTr/f6/XQNky5sjazNfjRUO uw6y069mysm1FB4LD2vGZT2VIB+QL+2ekRfUA0uJaGweVOr2TaxoKE6hQzWq4yThq0s+ iijXV1NhK/L+Vc2M+IJt+q5rfh02FHaPq3NQPPEtsG9xDuWhXabk8+NuN7aR4jPSrtAv wguasFLzpV8vea21TaE+NeOLY6pQfEWyF64nOrg9NVa+P3wO4v8VEc1Z/AbWNFsKRKCr kl08D8Yz2n1MbjwlNTwQ6jr6g1kVCtLePQl0sJ6b2sY+1TxXOAmbNApqFr5qUeeBA+GB goAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=JLx5uQU6POKTXM1+DX38rzmmgN8lknzYRrgfAACpD/o=; b=LVEQ/mK5sxpjcNaeEPXOFLjDHDAJSJNQrof6yIOzL1eltsxDzkndcxQQ65Bqt9zHSM nR0kRuCkJcvhhFiYmDduBvqEt0C2zKwoJViOGO0ZQI5RmrLgCDslOeN0CCn7znMA/r94 tKDw9Iq3HMa4SeS4JDdU30F6YJ+7IzAAhI5DOGSQfgKKUt9hkxRIxC57SFIRN8rarIRy TVQDXCLh3ZcLSX2cON5EkDzdEdZFkUohslmCm0NxNH+ipcyQKiMEMPeMLkAdyFH6W19Y 9upBHup+txKnyJvPBVbXJS0gF78hf1hK3wWPiF/4w9fEad4dKKKyXbsPuhpIVb/u+VUN JCHA== X-Gm-Message-State: ACrzQf0lt61qLP1VGXRl1hRua+BmPWTrZYPJBjGwkZPti+WJSh06fiOY FR8ASiAm9QP1wCQ7xPMQx/4= X-Google-Smtp-Source: AMsMyM7m47wneVPXBji304x1Ap+UGunj42IvrUR8m7YskZ3J6UWS7BiPQL1KqAQeHIdfYqaCmz6tEg== X-Received: by 2002:a05:6402:1004:b0:464:778:c516 with SMTP id c4-20020a056402100400b004640778c516mr17098805edu.348.1667626902987; Fri, 04 Nov 2022 22:41:42 -0700 (PDT) Original-Received: from Mini.fritz.box (p4fe3a85e.dip0.t-ipconnect.de. [79.227.168.94]) by smtp.gmail.com with ESMTPSA id x14-20020a170906134e00b0073022b796a7sm461927ejb.93.2022.11.04.22.41.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Nov 2022 22:41:42 -0700 (PDT) In-Reply-To: <87leoqwc4o.fsf@rfc20.org> (Matt Armstrong's message of "Fri, 04 Nov 2022 16:09:11 -0700") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: "bug-gnu-emacs" Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:247131 Archived-At: Matt Armstrong writes: > X-Debbugs-cc: Stefan Monnier > > This has been in my head for weeks but I haven't had time to dig into > it. Best get it in a bug. > > See the code for dump_interval_node() in pdumper.c below. > > Imagine 'node' has a left child. It will recurse to that child on line > 35. That child will recurse back to its parent on line 30. That parent > will recurse back to its left child on line 35. This will repeat until > the stack blows. All you need is two nodes in the tree. > > This is not an immediate issue today because apparently Emacs does not > dump any buffers with overlays present, or at least, never more than one > overlay. I suspect the right fix is to delete lines 26-30, or something > like that, but I can't claim I understand this code. > > 1 static dump_off > 2 dump_interval_node (struct dump_context *ctx, struct itree_node *node, > 3 dump_off parent_offset) > 4 { > 5 #if CHECK_STRUCTS && !defined (HASH_itree_node_50DE304F13) > 6 # error "itree_node changed. See CHECK_STRUCTS comment in config.h." > 7 #endif > 8 struct itree_node out; > 9 dump_object_start (ctx, &out, sizeof (out)); > 10 if (node->parent) > 11 dump_field_fixup_later (ctx, &out, node, &node->parent); > 12 if (node->left) > 13 dump_field_fixup_later (ctx, &out, node, &node->parent); > 14 if (node->right) > 15 dump_field_fixup_later (ctx, &out, node, &node->parent); > 16 DUMP_FIELD_COPY (&out, node, begin); > 17 DUMP_FIELD_COPY (&out, node, end); > 18 DUMP_FIELD_COPY (&out, node, limit); > 19 DUMP_FIELD_COPY (&out, node, offset); > 20 DUMP_FIELD_COPY (&out, node, otick); > 21 dump_field_lv (ctx, &out, node, &node->data, WEIGHT_STRONG); > 22 DUMP_FIELD_COPY (&out, node, red); > 23 DUMP_FIELD_COPY (&out, node, rear_advance); > 24 DUMP_FIELD_COPY (&out, node, front_advance); > 25 dump_off offset = dump_object_finish (ctx, &out, sizeof (out)); > 26 if (node->parent) > 27 dump_remember_fixup_ptr_raw > 28 (ctx, > 29 offset + dump_offsetof (struct itree_node, parent), > 30 dump_interval_node (ctx, node->parent, offset)); > 31 if (node->left) > 32 dump_remember_fixup_ptr_raw > 33 (ctx, > 34 offset + dump_offsetof (struct itree_node, left), > 35 dump_interval_node (ctx, node->left, offset)); > 36 if (node->right) > 37 dump_remember_fixup_ptr_raw > 38 (ctx, > 39 offset + dump_offsetof (struct itree_node, right), > 40 dump_interval_node (ctx, node->right, offset)); > 41 return offset; > 42 } Yes, I think you are right. Could we also rename dump_interval_node to dump_itree_node? There is another function dump_interval_tree for text properties, which is a bit confusing.