From: Ioannis Kappas <ioannis.kappas@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 57880@debbugs.gnu.org, akrl@sdf.org
Subject: 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 [thread overview]
Message-ID: <CAMRHuGB-W9xWrV++Wf-VE8JweoUr2Xfgt2MY6hnDF83xk6hP3Q@mail.gmail.com> (raw)
In-Reply-To: <83czbnud9d.fsf@gnu.org>
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
next prev parent reply other threads:[~2022-09-22 6:55 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-17 11:14 bug#57880: 28.1; Emacs crashes with native compilation on when some antivirus program is running on MS-Windows Ioannis Kappas
2022-09-19 8:13 ` Andrea Corallo
2022-09-20 16:43 ` Ioannis Kappas
2022-09-21 11:06 ` Eli Zaretskii
2022-09-21 17:19 ` Ioannis Kappas
2022-09-22 6:36 ` Eli Zaretskii
2022-09-22 6:55 ` Ioannis Kappas [this message]
2022-09-22 8:26 ` Eli Zaretskii
2022-09-22 20:46 ` Ioannis Kappas
2022-09-23 5:53 ` Eli Zaretskii
2022-09-23 16:43 ` Ioannis Kappas
2023-06-07 21:13 ` Andrea Corallo
2023-06-08 5:31 ` Eli Zaretskii
2022-09-21 19:26 ` Andrea Corallo
2022-09-22 6:38 ` Eli Zaretskii
2022-09-22 8:09 ` Andrea Corallo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMRHuGB-W9xWrV++Wf-VE8JweoUr2Xfgt2MY6hnDF83xk6hP3Q@mail.gmail.com \
--to=ioannis.kappas@gmail.com \
--cc=57880@debbugs.gnu.org \
--cc=akrl@sdf.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.