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

[Eli Zaretskii <eliz@gnu.org>]

> 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.