From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.emacs.devel Subject: Re: Loading tramp for dump goes into infinite regress Date: Wed, 27 Jul 2022 04:31:30 -0400 Message-ID: References: <8735erhrlg.fsf@gmx.de> <83wnc2g0n8.fsf@gnu.org> <83sfmqfxcb.fsf@gnu.org> <83a68yfp6j.fsf@gnu.org> <83r129e1op.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000004dda1005e4c53f55" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19775"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Michael Albinus , emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jul 27 10:38:02 2022 Return-path: Envelope-to: ged-emacs-devel@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 1oGcYL-0004yY-NN for ged-emacs-devel@m.gmane-mx.org; Wed, 27 Jul 2022 10:38:01 +0200 Original-Received: from localhost ([::1]:54112 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oGcYJ-00069F-AH for ged-emacs-devel@m.gmane-mx.org; Wed, 27 Jul 2022 04:37:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57334) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oGcSN-0002Xi-BR for emacs-devel@gnu.org; Wed, 27 Jul 2022 04:31:53 -0400 Original-Received: from mail-pj1-x1035.google.com ([2607:f8b0:4864:20::1035]:39658) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oGcSJ-0002QU-RO; Wed, 27 Jul 2022 04:31:49 -0400 Original-Received: by mail-pj1-x1035.google.com with SMTP id x24-20020a17090ab01800b001f21556cf48so1450389pjq.4; Wed, 27 Jul 2022 01:31:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oOHmOwD4gZZOdZynR75mq9NfsQugIXgQTZSQ/z0drBU=; b=Yzz50qPFve9zWkhYEEq0xqXjdn7sDWw4iBF3aDxC/2cl+AMNPVv2HEblVBCR8A/jDF X670PNXnMatMmfW/yDvE0qDuWT4ZLftaJN1z277XM2JUZMPy2Op9qHLyac/hvtKGx/Gv SbHCZkjrXNFjBtJns7NTNOzDcgP6FIWCvJv/tT9xvmFNUz9K84MqZjMJJSOzCMpj/fUV 5ywEe09Tn+6ggb2JSGK8jRRsVW4ptTOA8k6sR6dmDp/P4+M8xk1MTYnMZkeF6Jiy9D5q r2zQ88IBLPyVpQnMmYutcv0Q837gMz34uHkRRMDjgQ6NBMl58W5XC3zQ52Rg/EJw+W8/ gAag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oOHmOwD4gZZOdZynR75mq9NfsQugIXgQTZSQ/z0drBU=; b=P1/vFFmqy5hXrlmg2H65BbHg9oKL3iMDe3VIpktRKwwp6uoRiwW3Z/rhV/CE14aEr/ 9o9Lde4dwQY3Z82x1acvbmFQs0P3MAfmKS0oK5fNSUWCzRN7wDY6CO97T1k6w1kbQtFc OwES+c782B58T5SdUuncBfrWiJfxwOdgiJOV+HThptp9qh/ApckPCl435isRHJC34ZU0 lIJi+bysIz5ApWQ4r6zQ3F7LxjbGY37NaBkM6SC8Ta6ATLbqFw2zTxZR1qui+4ZuGzBN qCXH2aAx7xgyIThky6Vd6H+VJILxFCEJZzHozisj/3lxMdNO0kYlr9uxVvEsfO1aSACw N7gg== X-Gm-Message-State: AJIora9xlLDKo2CMnmj7IrH51JMH/Or8bzAwL2f5gN9VXlsB9364YnPK oReFVzLyAXY9AScsYuj89JwMHBujj0U1k9uXoz5E88VE X-Google-Smtp-Source: AGRyM1sStZEktgk+9GGVx34Xu18IUub0w4/YEF+ruJvGUYrNU/bhpnp6QtXeqUN3t2GzBTmFV43SEPdMaMb+fjEWcrQ= X-Received: by 2002:a17:90a:bc1:b0:1f2:435f:94bc with SMTP id x1-20020a17090a0bc100b001f2435f94bcmr3377710pjd.5.1658910705307; Wed, 27 Jul 2022 01:31:45 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::1035; envelope-from=owinebar@gmail.com; helo=mail-pj1-x1035.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:292733 Archived-At: --0000000000004dda1005e4c53f55 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 26, 2022, 10:48 PM Lynn Winebarger wrote: > On Tue, Jul 26, 2022 at 8:58 PM Lynn Winebarger > wrote: > > I was still seeing some runaway allocation even with native > > compilation completely disabled, so I finally fired up gdb and found > > the culprit: "lmalloc", which has a comment saying the "while (true)" > > loop shouldn't iterate on a modern platform. RHEL 7.9 isn't hot off > > the presses, but it's not that ancient. > > I'll try to replicate on a personal machine and file a bug, but it's > > not clear what triggers the condition. When it does occur, it always > > occurs at the same place. One instance was from loading cc-mode in > > site-load (after byte-compiling all the dependencies in the correct > > order). I wrapped the "defun c-init-language-vars-for" sexp in an > > eval, based on a comment in another one of the cc-* files (i.e. > > cargo-cult programming on my part), and that stopped the runaway > > allocation. But then it happened while loading ibuffer.el. > > Wrong again - the infinite loop is in pure_alloc. It looks like there > is a 10,655 character string in ibuffer.el on which pure_copy is being > called, and pure_alloc only adds increments of 10k. > This I can report as a bug. > The segmentation faults I've seen are also coming from purecopy. It's attempting to traverse a cyclic lisp structure and overflows the stack. I'm going guess this kind of thing is why Stefan Monnier and Pip Cet were enthusiastic about ditching pure space. Lynn --0000000000004dda1005e4c53f55 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 26, 2022, 10:48 PM Lynn Winebarger <owinebar@gmail.com> wrote:
On Tue, Jul 26, 2022 at 8:58 PM Lynn Winebarger &= lt;owinebar@gmail.com> wrote:
> I was still seeing some runaway allocation even with native
> compilation completely disabled, so I finally fired up gdb and found > the culprit:=C2=A0 "lmalloc", which has a comment saying the= "while (true)"
> loop shouldn't iterate on a modern platform.=C2=A0 RHEL 7.9 isn= 9;t hot off
> the presses, but it's not that ancient.
> I'll try to replicate on a personal machine and file a bug, but it= 's
> not clear what triggers the condition. When it does occur, it always > occurs at the same place.=C2=A0 One instance was from loading cc-mode = in
> site-load (after byte-compiling all the dependencies in the correct > order).=C2=A0 I wrapped the "defun c-init-language-vars-for"= sexp in an
> eval, based on a comment in another one of the cc-* files (i.e.
> cargo-cult programming on my part), and that stopped the runaway
> allocation.=C2=A0 But then it happened while loading ibuffer.el.

Wrong again - the infinite loop is in pure_alloc.=C2=A0 It looks like there=
is a 10,655 character string in ibuffer.el on which pure_copy is being
called, and pure_alloc only adds increments of 10k.
This I can report as a bug.
<= br>
The segmentation faults I've seen are also c= oming from purecopy.=C2=A0 It's attempting to traverse a cyclic lisp st= ructure and overflows the stack.

I'm going guess this kind of thing is why Stefan Monnier and = Pip Cet were enthusiastic about ditching pure space.

Lynn



--0000000000004dda1005e4c53f55--