From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ioannis Kappas 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: Sat, 17 Sep 2022 12:14:36 +0100 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17948"; mail-complaints-to="usenet@ciao.gmane.io" To: 57880@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Sep 17 13:15:16 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 1oZVn1-0004XD-Un for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 17 Sep 2022 13:15:16 +0200 Original-Received: from localhost ([::1]:43736 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oZVn0-0001a0-Ce for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 17 Sep 2022 07:15:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35184) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oZVmp-0001Zm-Dc for bug-gnu-emacs@gnu.org; Sat, 17 Sep 2022 07:15:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46171) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oZVmp-00058p-5P for bug-gnu-emacs@gnu.org; Sat, 17 Sep 2022 07:15:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oZVmo-0005eU-N3 for bug-gnu-emacs@gnu.org; Sat, 17 Sep 2022 07:15:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ioannis Kappas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 17 Sep 2022 11:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 57880 X-GNU-PR-Package: emacs X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.166341329621692 (code B ref -1); Sat, 17 Sep 2022 11:15:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 17 Sep 2022 11:14:56 +0000 Original-Received: from localhost ([127.0.0.1]:45249 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oZVmi-0005do-9d for submit@debbugs.gnu.org; Sat, 17 Sep 2022 07:14:56 -0400 Original-Received: from lists.gnu.org ([209.51.188.17]:58250) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oZVmg-0005dg-26 for submit@debbugs.gnu.org; Sat, 17 Sep 2022 07:14:54 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44050) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oZVmf-0001ZC-S0 for bug-gnu-emacs@gnu.org; Sat, 17 Sep 2022 07:14:53 -0400 Original-Received: from mail-wr1-x435.google.com ([2a00:1450:4864:20::435]:36719) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oZVmd-00057K-R1 for bug-gnu-emacs@gnu.org; Sat, 17 Sep 2022 07:14:53 -0400 Original-Received: by mail-wr1-x435.google.com with SMTP id h8so32916621wrf.3 for ; Sat, 17 Sep 2022 04:14:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date; bh=+lD7gCODj6rQrMXTbb4jWn0bEQ0AL7K5L9/90ogW+nM=; b=ahjswAG07TGpUA2/YrktI7JM8/DrfnssM9JuwHTIciXwcOqGKZQVKEVLKh5A97zAzq Gg8h8UpyiSZsmggpvWXixzp/4sOp6Xu5Nuj96TM44u3ocFnhR+gGW8yXPDLyKkkdPmRz EbrmWotgvQ5cxVCFhwc8oecAk+jfmzaR0ktAd2ezhTiHWgpK+h2gKYbz7evcETnHS2GI 7pfJHoru7FmfZMZ9yid/3Yvc44ux0EbCTQSeWJt7f30RlRsbf1P0hqRziiT/B5LZhpzD V1r44qDZbZ5yHQkFpM7UspMvZiwN7c7AaiND4CoGNZLoMp+pSqFoRzxhtmDKGxo5jCtt 10YQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date; bh=+lD7gCODj6rQrMXTbb4jWn0bEQ0AL7K5L9/90ogW+nM=; b=xZbAIC3pJ/p4XWyRrjlB8vf6+vddhNh4GB/UQ2Ypz2YeeFBIyy0YpEwBc59H6f0KC9 KxbJ23bQVhiwaYsXgXokQy285Yh8vlcXqJAaYoskbF3IRM/orgQ1Pg8V/UoK6w7QrAia /R1JiIPRD6Mi+rL5B5S2A3JcLCssQi+LkUs565airzM6hAI7hXviptWaCj5YLYPIpSrt /5HpE+G8dXbg+hHrOUZWFwfE0otlOx4PoeJDr2RFJoUD/rpet5MPUzFFRUi/lnoP+DJk lW4moi75kJgvwkSh4xgTh8mdyaDEPDiOgqZQuA5sC+rQO3UOtOnyUrChWPu5DIxulnJz J7fA== X-Gm-Message-State: ACrzQf23HDhxfwg6prlyPeHqK5gWJxsrHrByn/tWqEzVCLjkC2lpbuvU WIvslbvPnWJ2uddn5RJAwKp7eeJn28T7jxcqveqNJ1Hnwt8= X-Google-Smtp-Source: AMsMyM5eANrc7GfpjyegwTP5QRNg8BefJBOxZPSzk56sTibXmCuKXcqsE2NIejt/7WTdaHl0/cEPN32CMHTep8NRFkI= X-Received: by 2002:adf:d1c6:0:b0:228:dff6:77b8 with SMTP id b6-20020adfd1c6000000b00228dff677b8mr5582354wrd.115.1663413287723; Sat, 17 Sep 2022 04:14:47 -0700 (PDT) Received-SPF: pass client-ip=2a00:1450:4864:20::435; envelope-from=ioannis.kappas@gmail.com; helo=mail-wr1-x435.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:242859 Archived-At: 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