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

Previous Next

Full log

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.

Previous Next

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