From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs 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 09:36:14 +0300 Message-ID: <83czbnud9d.fsf@gnu.org> References: <83o7v9ugv2.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19352"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 57880@debbugs.gnu.org, akrl@sdf.org To: Ioannis Kappas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Sep 22 08:37:43 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1obFqA-0004qZ-5H for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 22 Sep 2022 08:37:42 +0200 Original-Received: from localhost ([::1]:49956 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1obFq8-00064C-Vf for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 22 Sep 2022 02:37:41 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43752) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1obFpW-00063B-3D for bug-gnu-emacs@gnu.org; Thu, 22 Sep 2022 02:37:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36894) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1obFpV-0001xZ-Q6 for bug-gnu-emacs@gnu.org; Thu, 22 Sep 2022 02:37:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1obFpV-0007hF-Kz for bug-gnu-emacs@gnu.org; Thu, 22 Sep 2022 02:37:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 22 Sep 2022 06:37:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57880 X-GNU-PR-Package: emacs Original-Received: via spool by 57880-submit@debbugs.gnu.org id=B57880.166382857329518 (code B ref 57880); Thu, 22 Sep 2022 06:37:01 +0000 Original-Received: (at 57880) by debbugs.gnu.org; 22 Sep 2022 06:36:13 +0000 Original-Received: from localhost ([127.0.0.1]:35967 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1obFoj-0007g2-9f for submit@debbugs.gnu.org; Thu, 22 Sep 2022 02:36:13 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:37444) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1obFog-0007fo-QX for 57880@debbugs.gnu.org; Thu, 22 Sep 2022 02:36:11 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:52904) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1obFoa-0001sa-Uw; Thu, 22 Sep 2022 02:36:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=fgiqPPaGUBp5QiCAY1K2x8V13HKC3E9kig8nO7s4qf8=; b=eUiu90J7hlyC Q+2ovrCpGh1UOP9proG4t9z0UfD1nvkueETsGEQRDLEDCebTkepie+n0e+rALnPWJZsZlK5EpHoja 3bZnH+yTEqIPTD4c1pHYGD4OPAIXQC5Vra4o0As1sJoLoQOs9+KQVnldfw1Xb3CjXe5z1/sVtiFHe l8wq24l7pZiuu3NEQSaZAC5glcHgbyHTgFf6d0HCBzHQFet9LJPiJElMVzr9QRSyJj+IaXGSZvVT2 ptlqW2zECTMA+xfZQKpxGe1h91Lf/Bc6EHShcnVOW87v4ar0wb9lB2rx2+uYzUHtYoWOfDlbx37kA 1FnCW6hH838G1Mf4ySPpGQ==; Original-Received: from [87.69.77.57] (port=1968 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1obFoZ-00028e-81; Thu, 22 Sep 2022 02:36:04 -0400 In-Reply-To: (message from Ioannis Kappas on Wed, 21 Sep 2022 18:19:11 +0100) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:243396 Archived-At: > From: Ioannis Kappas > 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 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.