From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#60996: 29.0.60; Native compile fails to remove temp file for trampoline Date: Tue, 24 Jan 2023 14:56:00 +0200 Message-ID: <83wn5cgkgv.fsf@gnu.org> References: <74d13c46-5b26-9dd8-45dc-32b7fda25421@gmail.com> <833583ks9t.fsf@gnu.org> <86wn5evv70.fsf@gmail.com> <83r0vli9gr.fsf@gnu.org> <86edrku3w6.fsf@gmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2636"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 60996@debbugs.gnu.org To: Andy Moreton , Andrea Corallo Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jan 24 13:56:20 2023 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 1pKIqZ-0000Yf-TH for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 24 Jan 2023 13:56:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pKIqJ-0005pu-DN; Tue, 24 Jan 2023 07:56:03 -0500 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 1pKIqI-0005pa-Ct for bug-gnu-emacs@gnu.org; Tue, 24 Jan 2023 07:56:02 -0500 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 1pKIqI-00070A-4H for bug-gnu-emacs@gnu.org; Tue, 24 Jan 2023 07:56:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pKIqI-0003tW-08 for bug-gnu-emacs@gnu.org; Tue, 24 Jan 2023 07:56:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 24 Jan 2023 12:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60996 X-GNU-PR-Package: emacs Original-Received: via spool by 60996-submit@debbugs.gnu.org id=B60996.167456495814961 (code B ref 60996); Tue, 24 Jan 2023 12:56:01 +0000 Original-Received: (at 60996) by debbugs.gnu.org; 24 Jan 2023 12:55:58 +0000 Original-Received: from localhost ([127.0.0.1]:56095 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pKIqE-0003tF-6J for submit@debbugs.gnu.org; Tue, 24 Jan 2023 07:55:58 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:54626) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pKIqC-0003t1-35 for 60996@debbugs.gnu.org; Tue, 24 Jan 2023 07:55:57 -0500 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 1pKIq6-0006u7-Fs; Tue, 24 Jan 2023 07:55:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Ur4LjsPvmFdhJgnEKuch/vaX8V+g8K53zNb03gfv7YU=; b=ieqHZBDGvUIs MD8oaUNtg41KtuuPZMz1gtG8C1hEqzO/KwsLN7SG7TjLMDsyfAoRDdOznMdf/Dz2BM2LbHL83GTk6 g6Vdwn/R8zkNfcokHtbQyus3/AnpuQMYeWQBQ8P7ZwwY1nFDov4H8wY4prblPEqoFtk9BVwkx9mVx 7p2wBkAlb4Rme/wRxdFFYRSvFkJf2uGLRE0EvqWE8c5qvh0j4gtQ3YmWzombaJIJ7YaAhW2TfMico E3+QvgRoBk2S0nrkZNCsrTSfz1hQYVOJZRnB/kQrqfaKFO0xIUZzeYhJv2DWAcu2DgLq5Fml6P4Hz AZ/gDE/wjbCYEkdcjb6eAw==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pKIq5-0001vl-V3; Tue, 24 Jan 2023 07:55:50 -0500 In-Reply-To: <86edrku3w6.fsf@gmail.com> (message from Andy Moreton on Tue, 24 Jan 2023 01:18:01 +0000) 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: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:254046 Archived-At: > From: Andy Moreton > Date: Tue, 24 Jan 2023 01:18:01 +0000 > > >> /* If in this session there was ever a file loaded with this > >> name, rename it before loading, to make sure we always get a > >> new handle! */ > >> Lisp_Object tmp_filename = > >> Fmake_temp_file_internal (filename, Qnil, build_string (".eln.tmp"), > >> Qnil); > >> if (NILP (Ffile_writable_p (tmp_filename))) > >> comp_u->handle = dynlib_open_for_eln (SSDATA (encoded_filename)); > >> else > >> { > >> Frename_file (filename, tmp_filename, Qt); > >> comp_u->handle = dynlib_open_for_eln (SSDATA (ENCODE_FILE (tmp_filename))); > >> Frename_file (tmp_filename, filename, Qnil); > >> } > >> > >> The renaming results in the ".eln.tmp" suffixed name having an open > >> handle. That handle is still open when other code tries to delete > >> the renamed ".eln" file, which fails. > > > > The question is: why is that .eln.tmp file still open when we are > > trying to delete it? I hoped we'd be able to establish that, so that > > we could decide what to do about it. But I don't yet see the > > information which would explain why the file is still open. > > The file handle is returned from dynlib_open_for_eln (which came from a > LoadLibrary call in dylib_open). More below. > > > Do these *.eln.tmp file remain in %TEMP% after Emacs startup? If they > > remain there, then what happens if you exit Emacs and restart it? do > > these files remain there or are they deleted? IOW, if we just ignore > > these errors (e.g., by ignore-error), would the problem be fixed, or > > will there be left-overs? > > The ".eln.tmp" suffixed files are only renamed temporarily, and the files > only fleetingly have that name. The ".eln" suffixed file names persist > after the failed delete, so will accumulate unless removed manually. So we are trying to delete a .eln file that is still being loaded into this same Emacs session? That sounds like a bug to me. Andrea, could you see if this situation can happen? IIUC, it should also happen on Unix when we compile a trampoline on the flight (perhaps when a previous outdated version of the trampoline exists?), except that on Unix the deletion silently succeeds and the file is removed when the session ends, which doesn't happen on Windows. On Windows, we need to unload the .eln file first, but can we do that with a trampoline? But first, I'd like to understand whether indeed it could happen that we are deleting a temporary .eln file for a trampoline we just compiled when we are still using that .eln file. If this happens, we'd need to find a way to delay the deletion till Emacs is about to exit or something.