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: Loading tramp for dump goes into infinite regress Date: Sat, 23 Jul 2022 20:47:08 -0400 Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000f28c8405e48268e8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26580"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jul 24 02:48:42 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 1oFPnW-0006l6-E6 for ged-emacs-devel@m.gmane-mx.org; Sun, 24 Jul 2022 02:48:42 +0200 Original-Received: from localhost ([::1]:49080 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oFPnU-00009O-Ts for ged-emacs-devel@m.gmane-mx.org; Sat, 23 Jul 2022 20:48:40 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40218) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oFPmH-0007tr-BL for emacs-devel@gnu.org; Sat, 23 Jul 2022 20:47:25 -0400 Original-Received: from mail-ot1-x335.google.com ([2607:f8b0:4864:20::335]:40679) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oFPmF-00075b-IP for emacs-devel@gnu.org; Sat, 23 Jul 2022 20:47:25 -0400 Original-Received: by mail-ot1-x335.google.com with SMTP id z12-20020a056830128c00b0061c8168d3faso6101199otp.7 for ; Sat, 23 Jul 2022 17:47:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=JICEyhsd7+gQ2UXxoeWRGV7UcAZ++lKaLyt//9f318A=; b=MG16/vmr6SNSIXPFlnZ5lLglk4lZ3blrUsa92TZ2o6ijgaZbn+l9Kw5CZRF+MxKWew QlJiY7G7fxLuLG5auuEF1ZufJbLOSYtcOGZj+tsF4365BL/3740o+yRPBTqp94qTmIh/ hin1m0NwBxcVj3pgX8gdi7HCiPygmtrUQpBYrnFGWnhn2azp5IyCH8xeG4mi1u+rVixS Fnt8oGBX8UBEqvY/ahqjFhg353nC0bZvYA+M+u073RVl6z2dmralMQR/ZWKqpK2ZwZoQ 09vd7z1yHdoeC25mw7e0zRZmNY0dN//fB3cHLvWC11nU4IJjFDhrKQLDVHDt6SScqVes 3oQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JICEyhsd7+gQ2UXxoeWRGV7UcAZ++lKaLyt//9f318A=; b=YDioA48JT+L1Q77Uv355+QFrJedUPkNlV2xlOnCxiBFobbXG/s7JZqtNeU3ZIByYCS sHXg3HUbfRNzxaHQtad9upFF8UPFvRpWXgyvhJs8c0tQ0KwbjpFZVBSLPPtRTK1bf/OU o7oc4fsgqUzAjYbdMhy9p+SREpERg8NXBe89de5C41dy/6O0BLUMHSaaHGffiS9OVz3A cLPJB2Bb1Iu25q0LQKqR8GFwqvyLWUbfywcZ1y7hSZXA55zuNaZS/mj3ZovEVGlF1Dk6 nGUAf7qV8pWcVjVaFWeH7dt4SIJCZaMRMaxYr7qp0xux+0+bbmkXw24/ZzE3sOfBtAkI IWNA== X-Gm-Message-State: AJIora9VYhqu83d00m7a14aE/MCc7icHQmqhkjkPAEOOpsKoY0QwPkif mg/PfFdFktlsDgeNn3hDr5b+FHNOkfkt0rG8v0HUSp9S X-Google-Smtp-Source: AGRyM1svo5v9lOE8i9We2eYRfVjT85boMHkehta/0SLvhnvXUqG4xhn67i3GWqJTCahlq8tWnYBK08Q+8OniSr4jFUk= X-Received: by 2002:a9d:1cb:0:b0:61c:a65b:c98 with SMTP id e69-20020a9d01cb000000b0061ca65b0c98mr2696224ote.2.1658623641146; Sat, 23 Jul 2022 17:47:21 -0700 (PDT) Received-SPF: pass client-ip=2607:f8b0:4864:20::335; envelope-from=owinebar@gmail.com; helo=mail-ot1-x335.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:292557 Archived-At: --000000000000f28c8405e48268e8 Content-Type: text/plain; charset="UTF-8" And I don't even know where to start describing the issue. It starts with having "(require 'tramp-loaddefs)" in tramp.el. That's a nonstarter for dumping, so I extracted all the variable/constant defs from tramp-loaddefs and put them in a separate file "tramp-consts.el", removed them from tramp-loaddefs, and then require the tramp-consts in tramp.el at the same place. I also added explicit declare-function for all the functions the compiler complaints about being missing. Then, at the end of the file, after the provide statement, I've tried various ways of having the effect of the "require tramp-loaddefs" call before the tramp init hook functions are run, since those are set in tramp-loaddefs. I tried just putting the require tramp-loaddefs there, loading tramp-loaddefs, explicitly loading the individual files (conditioned on dump-mode being nil), but all for naught. If I wrap the "provide 'tramp" call with eval-and-compile, the dump will successfully load it, but batch compiling it will fail on the "provide" saying that tramp-methods variable is void. This happens even if I've removed the expressions following the provide. And when I use "message" calls to track where it's failing, the procedure definitely fails on the provide. It seems to be triggering some load procedure that's pulling in the expressions created by tramp--with-startup, but I can't find the expression responsible! If I don't put the provide in an eval-and-compile, then the file compiled, but when I run the dumping process (via make), it gets to "loading net/tramp.elc" and just stops until all memory is consumed and the kernel kills it. Or I interrupt it. We're talking tens of GBs of RAM being consumed here. If that were "real" and not some runaway meta-recursive load cycle I wouldn't want the dumped emacs anyway. Any advice on how I figure out what is going on here? Thanks, Lynn --000000000000f28c8405e48268e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
And I don't even know where to start describing the i= ssue.
It starts with having "(require 'tramp-load= defs)" in tramp.el.=C2=A0 That's a nonstarter for dumping, so I ex= tracted all the variable/constant defs from tramp-loaddefs and put them in = a separate file "tramp-consts.el", removed them from tramp-loadde= fs, and then require the tramp-consts in tramp.el at the same place.=C2=A0 = I also added explicit declare-function for all the functions the compiler c= omplaints about being missing.=C2=A0=C2=A0
Then, at = the end of the file, after the provide statement, I've tried various wa= ys of having the effect of the "require tramp-loaddefs" call befo= re the tramp init hook functions are run, since those are set in tramp-load= defs.=C2=A0 I tried just putting the require tramp-loaddefs there, loading = tramp-loaddefs, explicitly loading the individual files (conditioned on dum= p-mode being nil), but all for naught.

If I wrap the "provide 'tramp" call with eval-= and-compile, the dump will successfully load it, but batch compiling it wil= l fail on the "provide" saying that tramp-methods variable is voi= d.=C2=A0 This happens even if I've removed the expressions following th= e provide.=C2=A0 And when I use "message" calls to track where it= 's failing, the procedure definitely fails on the provide.=C2=A0 It see= ms to be triggering some load procedure that's pulling in the expressio= ns created by tramp--with-startup, but I can't find the expression resp= onsible!
If I don't put the provide in an eval-a= nd-compile, then the file compiled, but when I run the dumping process (via= make), it gets to "loading net/tramp.elc" and just stops until a= ll memory is consumed and the kernel kills it.=C2=A0 Or I interrupt it.=C2= =A0 We're talking tens of GBs of RAM being consumed here.=C2=A0 If that= were "real" and not some runaway meta-recursive load cycle I wou= ldn't want the dumped emacs anyway.

Any advice on how I figure out what is going on here?=C2=A0=

Thanks,
Lynn

--000000000000f28c8405e48268e8--