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

Previous Next

Full log

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

From: Ioannis Kappas <ioannis.kappas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 57880 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#57880: 28.1; Emacs crashes with native compilation on when
 some antivirus program is running on MS-Windows
Date: Thu, 22 Sep 2022 07:55:03 +0100

Hi Eli

On Thu, Sep 22, 2022 at 7:36 AM Eli Zaretskii <eliz <at> 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

Previous Next

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