bug#57880: 28.1; Emacs crashes with native compilation on when some antivirus program is running on MS-Windows

bug#57880: 28.1; Emacs crashes with native compilation on when some antivirus program is running on MS-Windows

[Ioannis Kappas]

Hi,

there appears to be an issue with native compilation and some
antivirus programs on MS-Windows that could cause Emacs to crash.

This can happen when the antivirus program rewires GetProcAddress
system fn to return NULL on a call to get the address of an exported
variable/function, of which native compilation makes use of to
identify features of the compiled code.

I can't think of any straightforward instructions to reproduce the
issue without such antivirus programs running, but the crash happens
when an .el file has been compiled and the native code is partially
loaded and then there is an attempt to unload it with the
unload_comp_unit fn below

src/comp.c:
void
unload_comp_unit (struct Lisp_Native_Comp_Unit *cu)
{
  if (cu->handle == NULL)
    return;

  Lisp_Object *saved_cu = dynlib_sym (cu->handle, COMP_UNIT_SYM);
  Lisp_Object this_cu;
  XSETNATIVE_COMP_UNIT (this_cu, cu);
  if (EQ (this_cu, *saved_cu))
    *saved_cu = Qnil;
  dynlib_close (cu->handle);
}

saved_cu is returned as NULL and the program crashes without an
indication what has might have gone wrong.

I suppose a partial fix to avoid the crash (which seems good to have
regardless of antivirus interference), would be to check for NULL
pointer

void
unload_comp_unit (struct Lisp_Native_Comp_Unit *cu)
{
  if (cu->handle == NULL)
    return;

  Lisp_Object *saved_cu = dynlib_sym (cu->handle, COMP_UNIT_SYM);
  if (saved_cu)
    {
      Lisp_Object this_cu;
      XSETNATIVE_COMP_UNIT (this_cu, cu);
      if (EQ (this_cu, *saved_cu))
*saved_cu = Qnil;
    }
  dynlib_close (cu->handle);
}

Not sure if there is much we can do to circumvent the antivirus
restrictions? This at least also affects dynamically loaded modules
from loading  (but Emacs doesn't crash here, just displays the
misleading "module is not GPL compatible" warning), since it employs
the same technique to check if modules are GPL compatible

DEFUN ("module-load", Fmodule_load, Smodule_load, 1, 1, 0,
       doc: /* Load module FILE.  */)
  (Lisp_Object file)
{
  dynlib_handle_ptr handle;
  emacs_init_function module_init;
  void *gpl_sym;

  CHECK_STRING (file);
  handle = dynlib_open (SSDATA (file));
  if (!handle)
    xsignal2 (Qmodule_open_failed, file, build_string (dynlib_error ()));

  gpl_sym = dynlib_sym (handle, "plugin_is_GPL_compatible");
  if (!gpl_sym)
    xsignal1 (Qmodule_not_gpl_compatible, file);

// ...
}

In some situations (or perhaps in most?), the antivirus only applies
these restrictions to dll/eln files loaded from certain directories,
such as the user home directory starting at c:\Users. In that case, it
is possible to use the XDG_CONFIG_HOME path to set the user directory
(where the .eln files are generated at) to another, unrestricted,
location:

> mkdir c:\xdg-config\emacs
> set XDG_CONFIG_HOME=c:\xdg-config
> emacs

and then check that the above has taken effect with C-h v  user-emacs-directory.

(For XDG_CONFIG_HOME to work properly, ~/.emacs.d should not exist,
see https://www.gnu.org/software/emacs/manual/html_node/emacs/Find-Init.html
)

Thanks

bug#57880: 28.1; Emacs crashes with native compilation on when some antivirus program is running on MS-Windows

[Andrea Corallo]

Ioannis Kappas <ioannis.kappas@gmail.com> writes:

> Hi,
>
> there appears to be an issue with native compilation and some
> antivirus programs on MS-Windows that could cause Emacs to crash.
>
> This can happen when the antivirus program rewires GetProcAddress
> system fn to return NULL on a call to get the address of an exported
> variable/function, of which native compilation makes use of to
> identify features of the compiled code.
>
> I can't think of any straightforward instructions to reproduce the
> issue without such antivirus programs running, but the crash happens
> when an .el file has been compiled and the native code is partially
> loaded and then there is an attempt to unload it with the
> unload_comp_unit fn below

Hi Ioannis,

I'm not sure I understand why the issue is only in 'unload_comp_unit'
and not in all the other places where we use and rely on 'dynlib_sym'
(ex in 'make_subr').

Also I've a question (no windows expert here), can GetProcAddress return
NULL?

Thanks

  Andrea

bug#57880: 28.1; Emacs crashes with native compilation on when some antivirus program is running on MS-Windows

[Ioannis Kappas]

Hi Andrea,
On Mon, Sep 19, 2022 at 9:14 AM Andrea Corallo <akrl@sdf.org> wrote:

> I'm not sure I understand why the issue is only in 'unload_comp_unit'
> and not in all the other places where we use and rely on 'dynlib_sym'
> (ex in 'make_subr').

It is because `make_subr', or any of other relevant fns, is not given a
chance to execute. The eln file is loaded fine, but the search for the
COMP_UNIT_SYM'bol in the eln is unsuccessful (due to AV interference),
the file is considered invalid, and the only path left to take is to unload it.


> Also I've a question (no windows expert here), can GetProcAddress return
> NULL?

Yes, as per https://learn.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-getprocaddress:

  Return value

  If the function succeeds, the return value is the address of the
exported function or variable.

  If the function fails, the return value is NULL. To get extended
error information, call GetLastError.


I've also noticed another more surgical way to redirect the .eln cache
elsewhere, though is only available on the 29 branch:

;; in early-init.el
(when (> emacs-major-version 28)
  (startup-redirect-eln-cache "/to/a/safe/haven"))

Thanks

bug#57880: 28.1; Emacs crashes with native compilation on when some antivirus program is running on MS-Windows

[Eli Zaretskii]

> Cc: 57880@debbugs.gnu.org
> From: Ioannis Kappas <ioannis.kappas@gmail.com>
> Date: Tue, 20 Sep 2022 17:43:10 +0100
> 
> Hi Andrea,
> On Mon, Sep 19, 2022 at 9:14 AM Andrea Corallo <akrl@sdf.org> wrote:
> 
> > I'm not sure I understand why the issue is only in 'unload_comp_unit'
> > and not in all the other places where we use and rely on 'dynlib_sym'
> > (ex in 'make_subr').
> 
> It is because `make_subr', or any of other relevant fns, is not given a
> chance to execute. The eln file is loaded fine, but the search for the
> COMP_UNIT_SYM'bol in the eln is unsuccessful (due to AV interference),
> the file is considered invalid, and the only path left to take is to unload it.

What would be the purpose of using Emacs with native-compilation on
such a system?  Users who must cope with such antivirus programs will
need to use Emacs without native-compilation.  I see no good reason to
prevent Emacs from crashing, since those *.eln files cannot be used
anyway, and we will just have a slowed-down Emacs without
native-compilation.  Right?  Or did I miss something?

bug#57880: 28.1; Emacs crashes with native compilation on when some antivirus program is running on MS-Windows

[Ioannis Kappas]

Hi Eli,

On Wed, Sep 21, 2022 at 12:06 PM Eli Zaretskii <eliz@gnu.org> wrote:

> What would be the purpose of using Emacs with native-compilation on
> such a system?   Users who must cope with such antivirus programs will
> need to use Emacs without native-compilation.  I see no good reason to
> prevent Emacs from crashing, since those *.eln files cannot be used
> anyway, and we will just have a slowed-down Emacs without
> native-compilation.  Right?  Or did I miss something?

A user who experience this issue for the first time and had Emacs crash,
would have no indication whatsoever what hit them, i.e. they wouldn't
know how to
react. Thus my suggestion for checking for the NULL pointer in
unload comp, so that they at least see the error message about
the .eln files being inconsistent and research ways to go around it.

And I can see two ways going forward:
1. Take a step back and switch off native compilation (but how to do this
other than recompiling Emacs?)
2. Stil use native compilation but change the destination .eln directory
  to a safer path, so that they can still rip the benefit. I'd expect the AV
only have a limited set of dirs preventing GetProcAddress of
operating, otherwise nothing would work.

Thanks

bug#57880: 28.1; Emacs crashes with native compilation on when some antivirus program is running on MS-Windows

[Andrea Corallo]

Ioannis Kappas <ioannis.kappas@gmail.com> writes:

> Hi Andrea,
> On Mon, Sep 19, 2022 at 9:14 AM Andrea Corallo <akrl@sdf.org> wrote:
>
>> I'm not sure I understand why the issue is only in 'unload_comp_unit'
>> and not in all the other places where we use and rely on 'dynlib_sym'
>> (ex in 'make_subr').
>
> It is because `make_subr', or any of other relevant fns, is not given a
> chance to execute. The eln file is loaded fine, but the search for the
> COMP_UNIT_SYM'bol in the eln is unsuccessful (due to AV interference),
> the file is considered invalid, and the only path left to take is to unload it.
>
>
>> Also I've a question (no windows expert here), can GetProcAddress return
>> NULL?
>
> Yes, as per https://learn.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-getprocaddress:
>
>   Return value
>
>   If the function succeeds, the return value is the address of the
> exported function or variable.
>
>   If the function fails, the return value is NULL. To get extended
> error information, call GetLastError.

Okay, I think then is a good idea to guard against the NULL pointer
potentially returned, OTOH we do it already in the rest of the code.

I'm only not sure if we should signal an error or not here.

  Andrea

bug#57880: 28.1; Emacs crashes with native compilation on when some antivirus program is running on MS-Windows

[Eli Zaretskii]

> From: Ioannis Kappas <ioannis.kappas@gmail.com>
> Date: Wed, 21 Sep 2022 18:19:11 +0100
> Cc: akrl@sdf.org, 57880@debbugs.gnu.org
> 
> On Wed, Sep 21, 2022 at 12:06 PM Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > What would be the purpose of using Emacs with native-compilation on
> > such a system?   Users who must cope with such antivirus programs will
> > need to use Emacs without native-compilation.  I see no good reason to
> > prevent Emacs from crashing, since those *.eln files cannot be used
> > anyway, and we will just have a slowed-down Emacs without
> > native-compilation.  Right?  Or did I miss something?
> 
> A user who experience this issue for the first time and had Emacs crash,
> would have no indication whatsoever what hit them, i.e. they wouldn't
> know how to
> react. Thus my suggestion for checking for the NULL pointer in
> unload comp, so that they at least see the error message about
> the .eln files being inconsistent and research ways to go around it.

How can an average user go about researching this?  They'd need a
debugger, a binary with debug info, and probably also a way of
compiling Emacs.  That doesn't sound like a typical Windows user to
me.

When Emacs crashes, they will report a bug, or ask on some forum.  We
can have this issue and its solutions described in PROBLEMS, so we
could point them to that place.  We could even mention this in the
README that accompanies the Windows binaries (if we believe users
actually read that).  One way or another, if this issue happens
frequently, the information will spread widely enough for people to be
able to find it by a simple Internet search.

Btw, which antivirus software have this "feature"?  If it's widely
used, perhaps the "official" Emacs binaries should not be distributed
with native-compilation enabled at all?

> And I can see two ways going forward:
> 1. Take a step back and switch off native compilation (but how to do this
> other than recompiling Emacs?)
> 2. Stil use native compilation but change the destination .eln directory
>   to a safer path, so that they can still rip the benefit. I'd expect the AV
> only have a limited set of dirs preventing GetProcAddress of
> operating, otherwise nothing would work.

Why does the directory where the *.eln files live matter?  Doesn't the
antivirus software check any loading of any DLL from anywhere on the
system?

In any case, the *.eln files have at least two places on any system,
and only one of them can be changed, the other one is fixed by the
build.

bug#57880: 28.1; Emacs crashes with native compilation on when some antivirus program is running on MS-Windows

[Eli Zaretskii]

> Cc: 57880@debbugs.gnu.org
> From: Andrea Corallo <akrl@sdf.org>
> Date: Wed, 21 Sep 2022 19:26:08 +0000
> 
> Okay, I think then is a good idea to guard against the NULL pointer
> potentially returned, OTOH we do it already in the rest of the code.
> 
> I'm only not sure if we should signal an error or not here.

No, we shouldn't, IMO.  We should just behave as if the *.eln files
were unavailable, perhaps with some message logged in *Messages*.
Signaling an error would be shooting the user in his/her foot, because
loading of *.eln files is attempted as part of routine operation, so
signaling an error will prevent the user from being able to invoke
many commands.

bug#57880: 28.1; Emacs crashes with native compilation on when some antivirus program is running on MS-Windows

[Ioannis Kappas]

Hi Eli

On Thu, Sep 22, 2022 at 7:36 AM Eli Zaretskii <eliz@gnu.org> wrote:

> How can an average user go about researching this?  They'd need a
> debugger, a binary with debug info, and probably also a way of
> compiling Emacs.  That doesn't sound like a typical Windows user to
> me.

There will get a lot of "eln file inconsistent with current runtime" messages
in Emacs warnings buffer, the users will search on the Internet, and
they eventually
notice this discussion, mentioning the possible workarounds.

> When Emacs crashes, they will report a bug, or ask on some forum.  We
> can have this issue and its solutions described in PROBLEMS, so we
> could point them to that place.

If Emacs just crashes with not the slightest indication what has gone wrong,
they have to go through a bug report, of which the average user won't do.

> We could even mention this in the
> README that accompanies the Windows binaries (if we believe users
> actually read that).  One way or another, if this issue happens
> frequently, the information will spread widely enough for people to be
> able to find it by a simple Internet search.

There is always the possibility this issue happens frequently but
there are no reports, users then just move one with other tooling, which
means the user base is reduced.

> Btw, which antivirus software have this "feature"?  If it's widely
> used, perhaps the "official" Emacs binaries should not be distributed
> with native-compilation enabled at all?

Or could there be an early init option to bypass the native compilation. This
way the users can test the issue with is native comp.

> > And I can see two ways going forward:
> > 1. Take a step back and switch off native compilation (but how to do this
> > other than recompiling Emacs?)
> > 2. Stil use native compilation but change the destination .eln directory
> >   to a safer path, so that they can still rip the benefit. I'd expect the AV
> > only have a limited set of dirs preventing GetProcAddress of
> > operating, otherwise nothing would work.
>
> Why does the directory where the *.eln files live matter?  Doesn't the
> antivirus software check any loading of any DLL from anywhere on the
> system?

Perhaps it only matters for the User directory. AVs want to put more
stricter control
on the binaries the user downloads and installs themselves.

> In any case, the *.eln files have at least two places on any system,
> and only one of them can be changed, the other one is fixed by the
> build.

Those precompiled with Emacs are fine in this use case since they are
not stored in the Users directory, it's only newly compiled files that
exhibit this issue because they store the .eln files in the user dir by
default.

Thanks

bug#57880: 28.1; Emacs crashes with native compilation on when some antivirus program is running on MS-Windows

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: 57880@debbugs.gnu.org
>> From: Andrea Corallo <akrl@sdf.org>
>> Date: Wed, 21 Sep 2022 19:26:08 +0000
>> 
>> Okay, I think then is a good idea to guard against the NULL pointer
>> potentially returned, OTOH we do it already in the rest of the code.
>> 
>> I'm only not sure if we should signal an error or not here.
>
> No, we shouldn't, IMO.  We should just behave as if the *.eln files
> were unavailable, perhaps with some message logged in *Messages*.
> Signaling an error would be shooting the user in his/her foot, because
> loading of *.eln files is attempted as part of routine operation, so
> signaling an error will prevent the user from being able to invoke
> many commands.

Agree.

  Andrea

bug#57880: 28.1; Emacs crashes with native compilation on when some antivirus program is running on MS-Windows

[Eli Zaretskii]

> From: Ioannis Kappas <ioannis.kappas@gmail.com>
> Date: Thu, 22 Sep 2022 07:55:03 +0100
> Cc: akrl@sdf.org, 57880@debbugs.gnu.org
> 
> Or could there be an early init option to bypass the native compilation. This
> way the users can test the issue with is native comp.

There is one already.

> > Why does the directory where the *.eln files live matter?  Doesn't the
> > antivirus software check any loading of any DLL from anywhere on the
> > system?
> 
> Perhaps it only matters for the User directory. AVs want to put more
> stricter control
> on the binaries the user downloads and installs themselves.

Is that known, or is this just a guess?

Also, I asked which AV software has this problem.  Do you happen to
know?

Anyway, programs are not normally installed under C:\Users, they are
installed under C:\Program Files.

> > In any case, the *.eln files have at least two places on any system,
> > and only one of them can be changed, the other one is fixed by the
> > build.
> 
> Those precompiled with Emacs are fine in this use case since they are
> not stored in the Users directory, it's only newly compiled files that
> exhibit this issue because they store the .eln files in the user dir by
> default.

This means that the problem will only affect people who have libgccjit
and GCC/Binutils installed, because otherwise Emacs will be unable to
compile new *.eln files.  Right?

bug#57880: 28.1; Emacs crashes with native compilation on when some antivirus program is running on MS-Windows

[Ioannis Kappas]

Hi Eli,

On Thu, Sep 22, 2022 at 9:26 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > Or could there be an early init option to bypass the native compilation. This
> > way the users can test the issue with is native comp.
>
> There is one already.

Are you referring to an option for building form source? I couldn't
find an option
to turn off native compile for the precompiled windows binaries (such as those
retrieved from the official ftp site or from msys2 pacman) that can configured
to disable native comp.

> > > Why does the directory where the *.eln files live matter?  Doesn't the
> > > antivirus software check any loading of any DLL from anywhere on the
> > > system?
> >
> > Perhaps it only matters for the User directory. AVs want to put more
> > stricter control
> > on the binaries the user downloads and installs themselves.
>
> Is that known, or is this just a guess?

This is an educated guess. The only facts are that
(1) Emacs crashes the moment it tries to read .eln files from the
  c:/Users/* directory,
(2) throws an "emacs module is not GPL compatible" error when
loading native modules from the same dir.
(3) and these are all side effect of trying to use GetProcAddress on a
 dll/eln file residing in the C:/Users/* dir. Both (1) and (2) work otherwise.

> Also, I asked which AV software has this problem.  Do you happen to
> know?

Here is an old article that I found published by the AV maker in question,
referring to how most of windows viruses use GetProcAddress

https://community.broadcom.com/symantecenterprise/viewdocument/fighting-epo-viruses

"""... . Most Windows viruses use the GetProcAddress API to obtain
needed API addresses for their future execution ... """

and I believe this the reasons why they try to restrict its use in the User's
directory, where it is unusual for mainstream programs to be installed,
as per your comment below.

>
> Anyway, programs are not normally installed under C:\Users, they are
> installed under C:\Program Files.

Correct, and I believe the AV exploits this, so that it puts stricter
controls on
the Users dir.

> > Those precompiled with Emacs are fine in this use case since they are
> > not stored in the Users directory, it's only newly compiled files that
> > exhibit this issue because they store the .eln files in the user dir by
> > default.
>
> This means that the problem will only affect people who have libgccjit
> and GCC/Binutils installed, because otherwise Emacs will be unable to
> compile new *.eln files.  Right?

Yes, since I understand Emacs won't be able to generate any new .eln files
without access to libgccjit.

Thanks

bug#57880: 28.1; Emacs crashes with native compilation on when some antivirus program is running on MS-Windows

[Eli Zaretskii]

> From: Ioannis Kappas <ioannis.kappas@gmail.com>
> Date: Thu, 22 Sep 2022 21:46:14 +0100
> Cc: akrl@sdf.org, 57880@debbugs.gnu.org
> 
> > > Or could there be an early init option to bypass the native compilation. This
> > > way the users can test the issue with is native comp.
> >
> > There is one already.
> 
> Are you referring to an option for building form source? I couldn't
> find an option
> to turn off native compile for the precompiled windows binaries (such as those
> retrieved from the official ftp site or from msys2 pacman) that can configured
> to disable native comp.

It's native-comp-deferred-compilation: set it to nil.  For a good
measure, also set comp-enable-subr-trampolines to nil.  Emacs does
this automatically at startup if libgccjit cannot be loaded.

> > > Perhaps it only matters for the User directory. AVs want to put more
> > > stricter control
> > > on the binaries the user downloads and installs themselves.
> >
> > Is that known, or is this just a guess?
> 
> This is an educated guess. The only facts are that
> (1) Emacs crashes the moment it tries to read .eln files from the
>   c:/Users/* directory,
> (2) throws an "emacs module is not GPL compatible" error when
> loading native modules from the same dir.
> (3) and these are all side effect of trying to use GetProcAddress on a
>  dll/eln file residing in the C:/Users/* dir. Both (1) and (2) work otherwise.

So you are saying that if someone installs Emacs under C:/Users, that
Emacs will not work, regardless of the native-compilation, because it
will be unable to load the DLLs which come in the Emacs binary
distribution, for example the image libraries?  Then it is strange
that we haven't heard about such a major issue with Emacs on Windows
until now.

> > Also, I asked which AV software has this problem.  Do you happen to
> > know?
> 
> Here is an old article that I found published by the AV maker in question,
> referring to how most of windows viruses use GetProcAddress
> 
> https://community.broadcom.com/symantecenterprise/viewdocument/fighting-epo-viruses
> 
> """... . Most Windows viruses use the GetProcAddress API to obtain
> needed API addresses for their future execution ... """
> 
> and I believe this the reasons why they try to restrict its use in the User's
> directory, where it is unusual for mainstream programs to be installed,
> as per your comment below.

Thanks, but that doesn't really answer my question, which was about
the specific brands of AV software _known_ to do this.  You seem to
saying that the answer is 'all of them", but I'm asking what are the
brands with which this was actually seen.

> > > Those precompiled with Emacs are fine in this use case since they are
> > > not stored in the Users directory, it's only newly compiled files that
> > > exhibit this issue because they store the .eln files in the user dir by
> > > default.
> >
> > This means that the problem will only affect people who have libgccjit
> > and GCC/Binutils installed, because otherwise Emacs will be unable to
> > compile new *.eln files.  Right?
> 
> Yes, since I understand Emacs won't be able to generate any new .eln files
> without access to libgccjit.

So then we can tell such people (which are relatively rare) to have
their home directory outside of the C:/Users tree.

bug#57880: 28.1; Emacs crashes with native compilation on when some antivirus program is running on MS-Windows

[Ioannis Kappas]

Hi Eli,

On Fri, Sep 23, 2022 at 6:53 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Ioannis Kappas <ioannis.kappas@gmail.com>
> > Date: Thu, 22 Sep 2022 21:46:14 +0100
> > Cc: akrl@sdf.org, 57880@debbugs.gnu.org
> >
> > > > Or could there be an early init option to bypass the native compilation. This
> > > > way the users can test the issue with is native comp.
> > >
> > > There is one already.
> >
> > Are you referring to an option for building form source? I couldn't
> > find an option
> > to turn off native compile for the precompiled windows binaries (such as those
> > retrieved from the official ftp site or from msys2 pacman) that can configured
> > to disable native comp.
>
> It's native-comp-deferred-compilation: set it to nil.  For a good
> measure, also set comp-enable-subr-trampolines to nil.  Emacs does
> this automatically at startup if libgccjit cannot be loaded.

Thanks, it's good to know, I could find any straight references about it
on the web.

> So you are saying that if someone installs Emacs under C:/Users, that
> Emacs will not work, regardless of the native-compilation, because it
> will be unable to load the DLLs which come in the Emacs binary
> distribution, for example the image libraries?  Then it is strange
> that we haven't heard about such a major issue with Emacs on Windows
> until now.

Correct. I can't comment on how widespread that is. I personally stayed with
the 27 branch until I discovered the surprising cause of the failure.
I would not have reported it with just a simple hexadecimals backtrace,
without a single clue what might have been going wrong.

> Thanks, but that doesn't really answer my question, which was about
> the specific brands of AV software _known_ to do this.  You seem to
> saying that the answer is 'all of them", but I'm asking what are the
> brands with which this was actually seen.

Sorry for being a mystic here. It is the AV made by the company who authored
the article.

>
> > > > Those precompiled with Emacs are fine in this use case since they are
> > > > not stored in the Users directory, it's only newly compiled files that
> > > > exhibit this issue because they store the .eln files in the user dir by
> > > > default.
> > >
> > > This means that the problem will only affect people who have libgccjit
> > > and GCC/Binutils installed, because otherwise Emacs will be unable to
> > > compile new *.eln files.  Right?
> >
> > Yes, since I understand Emacs won't be able to generate any new .eln files
> > without access to libgccjit.
>
> So then we can tell such people (which are relatively rare) to have
> their home directory outside of the C:/Users tree.

Or let them know of the alternatives, such as the use of
startup-redirect-eln-cache
so that they can direct the new .eln files somewhere else? I don't think people
would want their .emacs.d  to be located outside of the personal user
folder. (I am not sure if we are referring to the same subject :)

Thanks!

bug#57880: 28.1; Emacs crashes with native compilation on when some antivirus program is running on MS-Windows

[Andrea Corallo]

Ioannis Kappas <ioannis.kappas@gmail.com> writes:

> Hi Eli,
>
> On Fri, Sep 23, 2022 at 6:53 AM Eli Zaretskii <eliz@gnu.org> wrote:
>>
>> > From: Ioannis Kappas <ioannis.kappas@gmail.com>
>> > Date: Thu, 22 Sep 2022 21:46:14 +0100
>> > Cc: akrl@sdf.org, 57880@debbugs.gnu.org
>> >
>> > > > Or could there be an early init option to bypass the native compilation. This
>> > > > way the users can test the issue with is native comp.
>> > >
>> > > There is one already.
>> >
>> > Are you referring to an option for building form source? I couldn't
>> > find an option
>> > to turn off native compile for the precompiled windows binaries (such as those
>> > retrieved from the official ftp site or from msys2 pacman) that can configured
>> > to disable native comp.
>>
>> It's native-comp-deferred-compilation: set it to nil.  For a good
>> measure, also set comp-enable-subr-trampolines to nil.  Emacs does
>> this automatically at startup if libgccjit cannot be loaded.
>
> Thanks, it's good to know, I could find any straight references about it
> on the web.
>
>> So you are saying that if someone installs Emacs under C:/Users, that
>> Emacs will not work, regardless of the native-compilation, because it
>> will be unable to load the DLLs which come in the Emacs binary
>> distribution, for example the image libraries?  Then it is strange
>> that we haven't heard about such a major issue with Emacs on Windows
>> until now.
>
> Correct. I can't comment on how widespread that is. I personally stayed with
> the 27 branch until I discovered the surprising cause of the failure.
> I would not have reported it with just a simple hexadecimals backtrace,
> without a single clue what might have been going wrong.
>
>> Thanks, but that doesn't really answer my question, which was about
>> the specific brands of AV software _known_ to do this.  You seem to
>> saying that the answer is 'all of them", but I'm asking what are the
>> brands with which this was actually seen.
>
> Sorry for being a mystic here. It is the AV made by the company who authored
> the article.
>
>>
>> > > > Those precompiled with Emacs are fine in this use case since they are
>> > > > not stored in the Users directory, it's only newly compiled files that
>> > > > exhibit this issue because they store the .eln files in the user dir by
>> > > > default.
>> > >
>> > > This means that the problem will only affect people who have libgccjit
>> > > and GCC/Binutils installed, because otherwise Emacs will be unable to
>> > > compile new *.eln files.  Right?
>> >
>> > Yes, since I understand Emacs won't be able to generate any new .eln files
>> > without access to libgccjit.
>>
>> So then we can tell such people (which are relatively rare) to have
>> their home directory outside of the C:/Users tree.
>
> Or let them know of the alternatives, such as the use of
> startup-redirect-eln-cache
> so that they can direct the new .eln files somewhere else? I don't think people
> would want their .emacs.d  to be located outside of the personal user
> folder. (I am not sure if we are referring to the same subject :)
>
> Thanks!

Hello all,

I'm not sure, is there any action we should take for this bug or should
we close it?

Thanks!

  Andrea

bug#57880: 28.1; Emacs crashes with native compilation on when some antivirus program is running on MS-Windows

[Eli Zaretskii]

> From: Andrea Corallo <acorallo@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  57880@debbugs.gnu.org,  akrl@sdf.org
> Date: Wed, 07 Jun 2023 17:13:42 -0400
> 
> I'm not sure, is there any action we should take for this bug or should
> we close it?

I've now added an entry about this to etc/PROBLEMS, and I'm therefore
closing this bug.