GNU bug report logs - #62004
30.0.50; comp-run-async-workers failure when default-directory deleted

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 62004 in the body.
You can then email your comments to 62004 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: No Wayman <iarchivedmywholelife <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; comp-run-async-workers failure when default-directory deleted
Date: Mon, 06 Mar 2023 10:48:58 -0500

A corner case I've recently run into with comp-run-async-workers:

1. create a non-empty elisp file at /tmp/dir/test.el
2. visit /tmp/dir/test.el
3. delete /tmp/dir/
4. from within the test.el buffer `M-x 
emacs-lisp-native-compile-and-load`

The process will fail with:

> /tmp/dir/test.el: Opening input file, No such file or directory, 
> /tmp/dir/test.el

A similar edge case is accounted for when the buffer has no 
associated file.
e.g. attempting emacs-lisp-native-compile-and-load from the 
*scratch* buffer results in the user error: 

> The buffer must be saved in a file first.

Perhaps a similar check should be made in the case described 
above.


In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.36, cairo version 1.17.8) of 2023-02-06 built on nbook
Repository revision: 907fd1f7ff402f9d226ebb3b891ea5b54fac1d1c
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 
11.0.12101006
System Description: Arch Linux

Message #8 received at 62004 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: No Wayman <iarchivedmywholelife <at> gmail.com>, Andrea Corallo <akrl <at> sdf.org>
Cc: 62004 <at> debbugs.gnu.org
Subject: Re: bug#62004: 30.0.50;
 comp-run-async-workers failure when default-directory deleted
Date: Mon, 06 Mar 2023 18:49:09 +0200

> From: No Wayman <iarchivedmywholelife <at> gmail.com>
> Date: Mon, 06 Mar 2023 10:48:58 -0500
> 
> 
> A corner case I've recently run into with comp-run-async-workers:
> 
> 1. create a non-empty elisp file at /tmp/dir/test.el
> 2. visit /tmp/dir/test.el
> 3. delete /tmp/dir/
> 4. from within the test.el buffer `M-x 
> emacs-lisp-native-compile-and-load`
> 
> The process will fail with:
> 
> > /tmp/dir/test.el: Opening input file, No such file or directory, 
> > /tmp/dir/test.el
> 
> A similar edge case is accounted for when the buffer has no 
> associated file.
> e.g. attempting emacs-lisp-native-compile-and-load from the 
> *scratch* buffer results in the user error: 
> 
> > The buffer must be saved in a file first.
> 
> Perhaps a similar check should be made in the case described 
> above.

That's not the same check: the latter checks whether the buffer visits
a file, which in the former case is true.

I'm not sure we should do anything here: after all, the error message
tells what's wrong quite clearly.  Andrea, WDYT?

Message #11 received at 62004 <at> debbugs.gnu.org (full text, mbox):

From: No Wayman <iarchivedmywholelife <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62004 <at> debbugs.gnu.org, Andrea Corallo <akrl <at> sdf.org>
Subject: Re: bug#62004: 30.0.50; comp-run-async-workers failure when
 default-directory deleted
Date: Mon, 06 Mar 2023 12:20:21 -0500

Eli Zaretskii <eliz <at> gnu.org> writes:

> That's not the same check

I'm aware. That's why I chose "similar" over "same".

> I'm not sure we should do anything here: after all, the error 
> message
> tells what's wrong quite clearly.

If it's the caller's responsibility to ensure a subprocess is 
invoked from an existing directory, fair enough.
This is one such case where that is not guaranteed, though.
I've seen similar errors pop up in other packages.
It would probably be better to offer a way to ensure the 
subprocess is run in an existing directory in general.
Is there an elisp idiom for such cases? e.g.

>(let ((default-directory (guaranteed-to-exist-directory)))
>  ;; start subprocess
> )

Message #14 received at 62004 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: No Wayman <iarchivedmywholelife <at> gmail.com>
Cc: 62004 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#62004: 30.0.50; comp-run-async-workers failure when
 default-directory deleted
Date: Mon, 06 Mar 2023 20:31:27 +0200

> From: No Wayman <iarchivedmywholelife <at> gmail.com>
> Cc: Andrea Corallo <akrl <at> sdf.org>, 62004 <at> debbugs.gnu.org
> Date: Mon, 06 Mar 2023 12:20:21 -0500
> 
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > I'm not sure we should do anything here: after all, the error 
> > message
> > tells what's wrong quite clearly.
> 
> If it's the caller's responsibility to ensure a subprocess is 
> invoked from an existing directory, fair enough.

I don't think this is about the directory where the subprocess is
invoked, I think this is about the .el file not being present.  Emacs
needs the file that is being natively-compiled to exist as a file on
disk.

Andrea, am I right?

Message #17 received at 62004 <at> debbugs.gnu.org (full text, mbox):

From: No Wayman <iarchivedmywholelife <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62004 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#62004: 30.0.50; comp-run-async-workers failure when
 default-directory deleted
Date: Mon, 06 Mar 2023 13:46:39 -0500

Eli Zaretskii <eliz <at> gnu.org> writes:

> I don't think this is about the directory where the subprocess 
> is
> invoked, I think this is about the .el file not being present. 
> Emacs
> needs the file that is being natively-compiled to exist as a 
> file on
> disk.

The example I gave used the emacs-lisp-native-compile-and-load 
directly because it is the simplest way to reproduce the error.
The same error can happen if the jit native compilation kicks in 
(because an entirely different feature is loaded but needs to be 
jit compiled) while in the buffer which no longer has a file 
associated with it.

Message #20 received at 62004 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: No Wayman <iarchivedmywholelife <at> gmail.com>
Cc: 62004 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#62004: 30.0.50; comp-run-async-workers failure when
 default-directory deleted
Date: Mon, 06 Mar 2023 22:10:19 +0200

> From: No Wayman <iarchivedmywholelife <at> gmail.com>
> Cc: akrl <at> sdf.org, 62004 <at> debbugs.gnu.org
> Date: Mon, 06 Mar 2023 13:46:39 -0500
> 
> The example I gave used the emacs-lisp-native-compile-and-load 
> directly because it is the simplest way to reproduce the error.
> The same error can happen if the jit native compilation kicks in 
> (because an entirely different feature is loaded but needs to be 
> jit compiled) while in the buffer which no longer has a file 
> associated with it.

Sorry, I don't think I understand.  Are you saying that we don't bind
default-directory to a safe value when compiling?  IOW, how could a
directory where the async compilation subprocess runs become invalid,
in Real Life?

Message #23 received at 62004 <at> debbugs.gnu.org (full text, mbox):

From: No Wayman <iarchivedmywholelife <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62004 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#62004: 30.0.50; comp-run-async-workers failure when
 default-directory deleted
Date: Mon, 06 Mar 2023 16:29:19 -0500

Eli Zaretskii <eliz <at> gnu.org> writes:

> Sorry, I don't think I understand.  Are you saying that we don't 
> bind
> default-directory to a safe value when compiling?

Correct. The default-directory is dependent on where 
comp-run-async-workers happens to kick off.
This can be reliably reproduced by:

1. saving the following elisp into test.el:

--8<---------------cut here---------------start------------->8---
;; -*- lexical-binding: t; -*-
(let* ((tempdir (expand-file-name "./temp/" user-emacs-directory))
      (default-directory tempdir)
      (feat 'org))
 ;; Ensure fresh test dir
 (when (file-exists-p tempdir) (delete-file tempdir))
 (make-directory tempdir)
 ;; Ensure test feature is not loaded.
 (when (featurep feat) (unload-feature feat t))
 (setq initial-buffer-choice
       (lambda ()
         (with-current-buffer (find-file (expand-file-name 
         "./temp.txt" tempdir))
           (insert "My directory will be deleted.")
           (write-file (expand-file-name "./temp.txt" tempdir))
           (delete-directory tempdir 'recursive)
           (message "default-directory: %S" default-directory)
           ;; comp-run-async-workers kicked off by JIT 
           compilation here.
           ;; This buffer has a file-name, but the directory no 
           longer exists.
           (require feat)
           (get-buffer-create (buffer-file-name))))))
--8<---------------cut here---------------end--------------->8---

2. launching emacs in a temporary init directory via:

> $ rm -rf /tmp/comp.test/ && emacs 
> --init-directory=/tmp/comp.test/ -l test.el

This should result in a *Messages* buffer similar to:

> For information about GNU Emacs and the GNU system, type C-h 
> C-a.
> (New file)
> Saving file /tmp/comp.test/temp/temp.txt...
> Wrote /tmp/comp.test/temp/temp.txt
> default-directory: "/tmp/comp.test/temp/"
> comp-run-async-workers: Setting current directory: No such file 
> or directory, /tmp/comp.test/temp/

>  IOW, how could a directory where the async compilation 
>  subprocess runs become invalid, in Real Life?

I ran into this error in the wild by:

- Installing a package to review it.
- Deleting the package's repository, but still had the package's 
 main elisp buffer open/current.
- Ran a command, which loaded a package, which kicked off the JIT 
 comp process.

Message #26 received at 62004 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: No Wayman <iarchivedmywholelife <at> gmail.com>
Cc: 62004 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#62004: 30.0.50; comp-run-async-workers failure when
 default-directory deleted
Date: Tue, 07 Mar 2023 05:30:34 +0200

> From: No Wayman <iarchivedmywholelife <at> gmail.com>
> Cc: akrl <at> sdf.org, 62004 <at> debbugs.gnu.org
> Date: Mon, 06 Mar 2023 16:29:19 -0500
> 
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Sorry, I don't think I understand.  Are you saying that we don't 
> > bind
> > default-directory to a safe value when compiling?
> 
> Correct. The default-directory is dependent on where 
> comp-run-async-workers happens to kick off.

I'm not sure what would be a safe value for that.  We had a lot of
trouble in other cases where such a value was required.

Andrea, any ideas?  How come we never ran into this issue until now?
Is the default-directory value when native compilation is forked
somehow derived from the directory of the file being compiled?

> >  IOW, how could a directory where the async compilation 
> >  subprocess runs become invalid, in Real Life?
> 
> I ran into this error in the wild by:
> 
> - Installing a package to review it.
> - Deleting the package's repository, but still had the package's 
>   main elisp buffer open/current.
> - Ran a command, which loaded a package, which kicked off the JIT 
>   comp process.

That's a pretty unusual situation, IMO.

Message #29 received at 62004 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: 62004 <at> debbugs.gnu.org, iarchivedmywholelife <at> gmail.com
Subject: Re: bug#62004: 30.0.50; comp-run-async-workers failure when
 default-directory deleted
Date: Tue, 07 Mar 2023 15:17:13 +0200

> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: No Wayman <iarchivedmywholelife <at> gmail.com>,  62004 <at> debbugs.gnu.org
> Date: Tue, 07 Mar 2023 11:16:40 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Andrea, any ideas?  How come we never ran into this issue until now?
> 
> I guess it's a very unlikely condition that was never
> encountered/reported.
> 
> > Is the default-directory value when native compilation is forked
> > somehow derived from the directory of the file being compiled?
> 
> If it is is not evident to me why.  We spawan something of this kind
> 
> /pathtoemacs/emacs -Q -batch -l /tmp/emacs-async-comp-something.el
> 
> where emacs-async-comp-something.el contains the actual setup (where we
> don't touch default-directory) and compilation command.
> 
> I'm probably missing something ATM.

Well, maybe we should bind the variable to be on the safe side?  What
if we bind it to the directory where we write that
emacs-async-comp-something.el file?

Message #32 received at 62004 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62004 <at> debbugs.gnu.org, iarchivedmywholelife <at> gmail.com
Subject: Re: bug#62004: 30.0.50; comp-run-async-workers failure when
 default-directory deleted
Date: Tue, 07 Mar 2023 13:51:37 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Andrea Corallo <akrl <at> sdf.org>
>> Cc: No Wayman <iarchivedmywholelife <at> gmail.com>,  62004 <at> debbugs.gnu.org
>> Date: Tue, 07 Mar 2023 11:16:40 +0000
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > Andrea, any ideas?  How come we never ran into this issue until now?
>> 
>> I guess it's a very unlikely condition that was never
>> encountered/reported.
>> 
>> > Is the default-directory value when native compilation is forked
>> > somehow derived from the directory of the file being compiled?
>> 
>> If it is is not evident to me why.  We spawan something of this kind
>> 
>> /pathtoemacs/emacs -Q -batch -l /tmp/emacs-async-comp-something.el
>> 
>> where emacs-async-comp-something.el contains the actual setup (where we
>> don't touch default-directory) and compilation command.
>> 
>> I'm probably missing something ATM.
>
> Well, maybe we should bind the variable to be on the safe side?  What
> if we bind it to the directory where we write that
> emacs-async-comp-something.el file?

Maybe but the reporter says "The default-directory is dependent on where
comp-run-async-workers happens to kick off." and I don't understand if
that's correct why is that.

I'd like first to understand better the issue here.

  Andrea

Message #35 received at 62004 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: 62004 <at> debbugs.gnu.org, iarchivedmywholelife <at> gmail.com
Subject: Re: bug#62004: 30.0.50; comp-run-async-workers failure when
 default-directory deleted
Date: Tue, 07 Mar 2023 16:16:38 +0200

> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: iarchivedmywholelife <at> gmail.com, 62004 <at> debbugs.gnu.org
> Date: Tue, 07 Mar 2023 13:51:37 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Well, maybe we should bind the variable to be on the safe side?  What
> > if we bind it to the directory where we write that
> > emacs-async-comp-something.el file?
> 
> Maybe but the reporter says "The default-directory is dependent on where
> comp-run-async-workers happens to kick off." and I don't understand if
> that's correct why is that.
> 
> I'd like first to understand better the issue here.

I agree that we should first have a good understanding of the
situation.  Let me know if I can help in any way.

Message #38 received at 62004 <at> debbugs.gnu.org (full text, mbox):

From: No Wayman <iarchivedmywholelife <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62004 <at> debbugs.gnu.org, Andrea Corallo <akrl <at> sdf.org>
Subject: Re: bug#62004: 30.0.50; comp-run-async-workers failure when
 default-directory deleted
Date: Tue, 07 Mar 2023 10:20:28 -0500

>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > Well, maybe we should bind the variable to be on the safe 
>> > side?  What
>> > if we bind it to the directory where we write that
>> > emacs-async-comp-something.el file?

Binding default-directory makes sense.
It's just a matter of what to bind it to.
I see that `comp-run-async-workers` calls `make-temp-file' 
internally.
Binding default-directory to temporary-file-directory around the 
call to `make-process' will prevent this error and seems like a 
safe bet.

>> From: Andrea Corallo <akrl <at> sdf.org>
>> Cc: iarchivedmywholelife <at> gmail.com, 62004 <at> debbugs.gnu.org
>> Date: Tue, 07 Mar 2023 13:51:37 +0000
>>
>> Maybe but the reporter says "The default-directory is dependent 
>> on where
>> comp-run-async-workers happens to kick off." and I don't 
>> understand if
>> that's correct why is that.
>> 
>> I'd like first to understand better the issue here.
>
> I agree that we should first have a good understanding of the
> situation.  Let me know if I can help in any way.

The call to `make-process' in `comp-run-async-workers' is executed 
in the context of whatever default-directory happens to be. If 
default-directory does not refer to an existing directory (as 
demonstrated in the reproduction case I provided) the creation of 
the subprocess will fail.
I'm not sure what more detail I can provide, so please ask a 
specific question if you have any.

Message #41 received at 62004 <at> debbugs.gnu.org (full text, mbox):

From: No Wayman <iarchivedmywholelife <at> gmail.com>
To: No Wayman <iarchivedmywholelife <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 62004 <at> debbugs.gnu.org,
 Andrea Corallo <akrl <at> sdf.org>
Subject: Re: bug#62004: 30.0.50; comp-run-async-workers failure when
 default-directory deleted
Date: Tue, 07 Mar 2023 10:53:58 -0500

[Message part 1 (text/plain, inline)]

No Wayman <iarchivedmywholelife <at> gmail.com> writes:

> Binding default-directory makes sense.
> It's just a matter of what to bind it to.
> I see that `comp-run-async-workers` calls `make-temp-file' 
> internally.
> Binding default-directory to temporary-file-directory around the 
> call to
> `make-process' will prevent this error and seems like a safe 
> bet.

The attached patch implements this and fixes the error on my end. 

[0001-comp.el-comp-run-async-workers-bind-default-director.patch (text/x-patch, attachment)]

Message #44 received at 62004 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: No Wayman <iarchivedmywholelife <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 62004 <at> debbugs.gnu.org
Subject: Re: bug#62004: 30.0.50; comp-run-async-workers failure when
 default-directory deleted
Date: Tue, 07 Mar 2023 16:00:39 +0000

No Wayman <iarchivedmywholelife <at> gmail.com> writes:

>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>>  > Well, maybe we should bind the variable to be on the safe  >
>>> side?  What
>>> > if we bind it to the directory where we write that
>>> > emacs-async-comp-something.el file?
>
> Binding default-directory makes sense.
> It's just a matter of what to bind it to.
> I see that `comp-run-async-workers` calls `make-temp-file' internally.
> Binding default-directory to temporary-file-directory around the call
> to `make-process' will prevent this error and seems like a safe bet.
>
>>> From: Andrea Corallo <akrl <at> sdf.org>
>>> Cc: iarchivedmywholelife <at> gmail.com, 62004 <at> debbugs.gnu.org
>>> Date: Tue, 07 Mar 2023 13:51:37 +0000
>>>
>>> Maybe but the reporter says "The default-directory is dependent on
>>> where
>>> comp-run-async-workers happens to kick off." and I don't understand
>>> if
>>> that's correct why is that.
>>> I'd like first to understand better the issue here.
>>
>> I agree that we should first have a good understanding of the
>> situation.  Let me know if I can help in any way.
>
> The call to `make-process' in `comp-run-async-workers' is executed in
> the context of whatever default-directory happens to be. If
> default-directory does not refer to an existing directory (as
> demonstrated in the reproduction case I provided) the creation of the
> subprocess will fail.
> I'm not sure what more detail I can provide, so please ask a specific
> question if you have any.

Ah now it's clear to me, the error is not happening in the child process
but in the main Emacs failing in running `make-process'.

Thanks

  Andrea

Message #47 received at 62004 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: No Wayman <iarchivedmywholelife <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 62004 <at> debbugs.gnu.org
Subject: Re: bug#62004: 30.0.50; comp-run-async-workers failure when
 default-directory deleted
Date: Tue, 07 Mar 2023 16:06:56 +0000

No Wayman <iarchivedmywholelife <at> gmail.com> writes:

> No Wayman <iarchivedmywholelife <at> gmail.com> writes:
>
>> Binding default-directory makes sense.
>> It's just a matter of what to bind it to.
>> I see that `comp-run-async-workers` calls `make-temp-file'
>> internally.
>> Binding default-directory to temporary-file-directory around the
>> call to
>> `make-process' will prevent this error and seems like a safe bet.
>
> The attached patch implements this and fixes the error on my end. >From fd33c2d58ac078ed53cdada5fa6e378e59247a3a Mon Sep 17 00:00:00 2001
> From: Nicholas Vollmer <iarchivedmywholelife <at> gmail.com>
> Date: Tue, 7 Mar 2023 10:44:17 -0500
> Subject: [PATCH] comp.el (comp-run-async-workers): bind default-directory
>
> Ensure default-directory exists prior to creating subprocess. (bug#62004)
> ---
>  lisp/emacs-lisp/comp.el | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/lisp/emacs-lisp/comp.el b/lisp/emacs-lisp/comp.el
> index ce81680a226..97cfa27a1aa 100644
> --- a/lisp/emacs-lisp/comp.el
> +++ b/lisp/emacs-lisp/comp.el
> @@ -4023,6 +4023,7 @@ comp-run-async-workers
>                          (comp-log "\n")
>                          (mapc #'comp-log expr-strings)))
>                     (load1 load)
> +                   (default-directory temporary-file-directory)
>                     (process (make-process
>                               :name (concat "Compiling: " source-file)
>                               :buffer (with-current-buffer

If tested LGTM, another option (maybe safer?) would be to use
`invocation-directory'.

Thanks

  Andrea

Message #50 received at 62004 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: 62004 <at> debbugs.gnu.org, iarchivedmywholelife <at> gmail.com
Subject: Re: bug#62004: 30.0.50; comp-run-async-workers failure when
 default-directory deleted
Date: Tue, 07 Mar 2023 18:14:26 +0200

> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 62004 <at> debbugs.gnu.org
> Date: Tue, 07 Mar 2023 16:06:56 +0000
> 
> No Wayman <iarchivedmywholelife <at> gmail.com> writes:
> 
> > No Wayman <iarchivedmywholelife <at> gmail.com> writes:
> >
> >> Binding default-directory makes sense.
> >> It's just a matter of what to bind it to.
> >> I see that `comp-run-async-workers` calls `make-temp-file'
> >> internally.
> >> Binding default-directory to temporary-file-directory around the
> >> call to
> >> `make-process' will prevent this error and seems like a safe bet.
> >
> > The attached patch implements this and fixes the error on my end. >From fd33c2d58ac078ed53cdada5fa6e378e59247a3a Mon Sep 17 00:00:00 2001
> > From: Nicholas Vollmer <iarchivedmywholelife <at> gmail.com>
> > Date: Tue, 7 Mar 2023 10:44:17 -0500
> > Subject: [PATCH] comp.el (comp-run-async-workers): bind default-directory
> >
> > Ensure default-directory exists prior to creating subprocess. (bug#62004)
> > ---
> >  lisp/emacs-lisp/comp.el | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/lisp/emacs-lisp/comp.el b/lisp/emacs-lisp/comp.el
> > index ce81680a226..97cfa27a1aa 100644
> > --- a/lisp/emacs-lisp/comp.el
> > +++ b/lisp/emacs-lisp/comp.el
> > @@ -4023,6 +4023,7 @@ comp-run-async-workers
> >                          (comp-log "\n")
> >                          (mapc #'comp-log expr-strings)))
> >                     (load1 load)
> > +                   (default-directory temporary-file-directory)
> >                     (process (make-process
> >                               :name (concat "Compiling: " source-file)
> >                               :buffer (with-current-buffer
> 
> If tested LGTM, another option (maybe safer?) would be to use
> `invocation-directory'.

I think I'd prefer invocation-directory, indeed.

Message #53 received at 62004 <at> debbugs.gnu.org (full text, mbox):

From: No Wayman <iarchivedmywholelife <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62004 <at> debbugs.gnu.org, Andrea Corallo <akrl <at> sdf.org>
Subject: Re: bug#62004: 30.0.50; comp-run-async-workers failure when
 default-directory deleted
Date: Tue, 07 Mar 2023 11:30:44 -0500

Eli Zaretskii <eliz <at> gnu.org> writes:

>> If tested LGTM, another option (maybe safer?) would be to use
>> `invocation-directory'.
>
> I think I'd prefer invocation-directory, indeed.

I don't see how temporary-file-directory is any less safe 
considering the function relies on make-temp-file, which uses that 
directory itself.
But feel free to alter the patch however you see fit.

Message #56 received at 62004 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: No Wayman <iarchivedmywholelife <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 62004 <at> debbugs.gnu.org
Subject: Re: bug#62004: 30.0.50; comp-run-async-workers failure when
 default-directory deleted
Date: Wed, 08 Mar 2023 20:19:30 +0000

Hi,

8a2a554192a should fix in 29.

Please let us know if we can close this.

Best Regards

  Andrea

Message #59 received at 62004 <at> debbugs.gnu.org (full text, mbox):

From: No Wayman <iarchivedmywholelife <at> gmail.com>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 62004 <at> debbugs.gnu.org
Subject: Re: bug#62004: 30.0.50; comp-run-async-workers failure when
 default-directory deleted
Date: Wed, 08 Mar 2023 15:51:26 -0500

Andrea Corallo <akrl <at> sdf.org> writes:

> Hi,
>
> 8a2a554192a should fix in 29.
>
> Please let us know if we can close this.
>
> Best Regards
>
>   Andrea

I won't have time to install the patch today, but it stands to 
reason that it will solve the problem.
I would consider this closed.
Thanks.

Message #64 received at 62004-done <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: No Wayman <iarchivedmywholelife <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 62004-done <at> debbugs.gnu.org
Subject: Re: bug#62004: 30.0.50; comp-run-async-workers failure when
 default-directory deleted
Date: Thu, 09 Mar 2023 09:25:46 +0000

No Wayman <iarchivedmywholelife <at> gmail.com> writes:

> Andrea Corallo <akrl <at> sdf.org> writes:
>
>> Hi,
>>
>> 8a2a554192a should fix in 29.
>>
>> Please let us know if we can close this.
>>
>> Best Regards
>>
>>   Andrea
>
> I won't have time to install the patch today, but it stands to reason
> that it will solve the problem.
> I would consider this closed.
> Thanks.

Done

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.