From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.bugs Subject: bug#46256: [feature/native-comp] AOT eln files ignored if run from build tree Date: Mon, 8 Mar 2021 06:48:40 +0000 Message-ID: References: <86eehujcip.fsf@gmail.com> <86blch14qt.fsf@gmail.com> <83h7m84h9g.fsf@gnu.org> <86v9ao5czu.fsf@gmail.com> <86wnutogrh.fsf@gmail.com> <86wnut8fb9.fsf@gmail.com> <861rd1tbpa.fsf@gmail.com> <83pn0km6y3.fsf@gnu.org> <86ft1f8ara.fsf@gmail.com> <83sg5cjdn8.fsf@gnu.org> <83r1kwjcy2.fsf@gnu.org> <8335x6u9o4.fsf@gnu.org> <83zgzesrku.fsf@gnu.org> <83tupms4mp.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="0000000000001d280905bd00d58d" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3688"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 46256@debbugs.gnu.org, andrewjmoreton@gmail.com, Andrea Corallo To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Mar 08 07:53:17 2021 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 1lJ9lU-0000rp-RW for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 08 Mar 2021 07:53:16 +0100 Original-Received: from localhost ([::1]:53644 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lJ9lT-0001oA-SP for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 08 Mar 2021 01:53:15 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53722) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lJ9iM-0006nS-LS for bug-gnu-emacs@gnu.org; Mon, 08 Mar 2021 01:50:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58608) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lJ9iM-0008Qj-Dw for bug-gnu-emacs@gnu.org; Mon, 08 Mar 2021 01:50:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lJ9iM-0006Sq-BY for bug-gnu-emacs@gnu.org; Mon, 08 Mar 2021 01:50:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 08 Mar 2021 06:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46256 X-GNU-PR-Package: emacs Original-Received: via spool by 46256-submit@debbugs.gnu.org id=B46256.161518616924804 (code B ref 46256); Mon, 08 Mar 2021 06:50:02 +0000 Original-Received: (at 46256) by debbugs.gnu.org; 8 Mar 2021 06:49:29 +0000 Original-Received: from localhost ([127.0.0.1]:41921 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lJ9ho-0006Rz-Iv for submit@debbugs.gnu.org; Mon, 08 Mar 2021 01:49:28 -0500 Original-Received: from mail-ot1-f54.google.com ([209.85.210.54]:40299) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lJ9hi-0006Rh-8n for 46256@debbugs.gnu.org; Mon, 08 Mar 2021 01:49:26 -0500 Original-Received: by mail-ot1-f54.google.com with SMTP id b8so8215096oti.7 for <46256@debbugs.gnu.org>; Sun, 07 Mar 2021 22:49:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w7d3QnlVieag0W3FrkEWl2EBJBP3zPZxNJy3GJGj82Q=; b=TILmeO6pA6BFcBxR2jbwDpuOaNnt+doHL0olpsb2pJjlkC1+xbTfJ4Du2Qoj16TWpJ R3bV7dXuLeJM3QLW1GPzi6wosh6/9rddWpuMBmbFyhSkLbzjVkAnf6TqsiAfTI5icRTY Vfmwhy+ibCGaneOMmad8yfnADnCjmiGzqeW0FAfnvkKG3UvmUeWWJ5mhPiZTR3VeaEBr VS4WlQz8OtcB5Mw4srBsCd4h5gLtEYbfhOE5RqVxJEh2HD8xkX72u+WYCsfsIu026fkN L0dU+NWwFctUXLKJGaVGVUQwGY0qk/FaGsk761TbytnNMzHAHBpdcLwV5LO15T1r/bID iGtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=w7d3QnlVieag0W3FrkEWl2EBJBP3zPZxNJy3GJGj82Q=; b=Xxgn7tn6iPB4biGdL6jJ1Dz9Qezxte5aMDcSKtaIfx5+1aDxoLu+rCFBPitJXcxGhY r3C4SMzBQh3gPTib5RXEPnm7A6Ksz8/KQzqfBdE9Ipp5vkwUxu7OzH+ZOpz4CrlPIX6h gzOgt7p8D9y+vfTaSa2DoPu1Jm7Wa/5SSupwZb4n/lLdvNQRjr/3V+dIYcjUFfELzBCN /CTabIqXNMMRnYcSmWRN0T9pwR8bVJ0ZIDBAGAAchwEbELIJlTdAvkICQjityHTOm2Rj BHqOA2UVI/Ed/1YqilxwTYGkgPQf1jNZ4OJZGSXg3SW+ONJcXI5iskvBKCfFXoABRkre C2xw== X-Gm-Message-State: AOAM533mwpYumZadzgH9QOXd+bi0jX0JYoTaQd1oJjweZi8URJMsRtXp gvdY2BwfTqZ0Nk7Rpgd45dPTluHc49tuAGmrMeo= X-Google-Smtp-Source: ABdhPJw8Uwge2J6AiHEwsrKF7RYFAbehmRblOpz7F1WWueE/M5RkJi0xplZCxcLpEhcMDjTxIVKiRdqu6difg+hD8EU= X-Received: by 2002:a05:6830:1e51:: with SMTP id e17mr18461873otj.292.1615186156653; Sun, 07 Mar 2021 22:49:16 -0800 (PST) In-Reply-To: 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:201807 Archived-At: --0000000000001d280905bd00d58d Content-Type: text/plain; charset="UTF-8" On Mon, Mar 8, 2021 at 5:54 AM Pip Cet wrote: > Note that this might not always work because of conservative GC. If it doesn't work, can you simply retry a few times? Eventually there shouldn't be references to the stale native_comp_unit on the stack. However, I think I've worked out why dynlib_close doesn't do its job: Fnative_elisp_load creates a comp unit, but, if the shared library has already been initialized, it doesn't set that comp unit's comp_unit variable to point to the new comp unit; instead, it will continue pointing to the first comp unit which still has it open. Then, the original comp unit is unloaded but not the new one created by Fnative_elisp_load. We call dynlib_close() once, but we called it twice before, leaving the shared library open and initialized. Then, we try to load the comp unit again, and follow the stale comp_unit variable pointing to the original comp unit. Fix should be as attached. Note the fix is, at worst, harmless (unless I messed up), so we should apply it anyway just because it's good not to leave stale pointers lying around even if we hope that the OS unmaps them at some point. Pip --0000000000001d280905bd00d58d Content-Type: text/x-patch; charset="US-ASCII"; name="0001-Fix-stale-pointers-in-comp-units-causing-crashes-bug.patch" Content-Disposition: attachment; filename="0001-Fix-stale-pointers-in-comp-units-causing-crashes-bug.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_km082jdu0 RnJvbSBhMmFiOTcwMWU0OGU1NDQzODA5NjY0ZDUwYzkyNGI5ZDgzMDYyYjRlIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBQaXAgQ2V0IDxwaXBjZXRAZ21haWwuY29tPgpEYXRlOiBTdW4s IDcgTWFyIDIwMjEgMjE6MjY6MjkgKzAwMDAKU3ViamVjdDogW1BBVENIXSBGaXggc3RhbGUgcG9p bnRlcnMgaW4gY29tcCB1bml0cyBjYXVzaW5nIGNyYXNoZXMgIChidWcjNDYyNTYpCgoqIHNyYy9h bGxvYy5jIChjbGVhbnVwX3ZlY3Rvcik6IENhbGwgdW5sb2FkX2NvbXBfdW5pdC4KKiBzcmMvY29t cC5jICh1bmxvYWRfY29tcF91bml0KTogTmV3IGZ1bmN0aW9uLgotLS0KIHNyYy9hbGxvYy5jIHwg IDMgKy0tCiBzcmMvY29tcC5jICB8IDE0ICsrKysrKysrKysrKysrCiBzcmMvY29tcC5oICB8ICAy ICsrCiAzIGZpbGVzIGNoYW5nZWQsIDE3IGluc2VydGlvbnMoKyksIDIgZGVsZXRpb25zKC0pCgpk aWZmIC0tZ2l0IGEvc3JjL2FsbG9jLmMgYi9zcmMvYWxsb2MuYwppbmRleCBhZjA4MzM2MTc3MDcw Li5mZWU4Y2MwOGFhNDgzIDEwMDY0NAotLS0gYS9zcmMvYWxsb2MuYworKysgYi9zcmMvYWxsb2Mu YwpAQCAtMzE1Nyw4ICszMTU3LDcgQEAgY2xlYW51cF92ZWN0b3IgKHN0cnVjdCBMaXNwX1ZlY3Rv ciAqdmVjdG9yKQogICAgIHsKICAgICAgIHN0cnVjdCBMaXNwX05hdGl2ZV9Db21wX1VuaXQgKmN1 ID0KIAlQU0VVRE9WRUNfU1RSVUNUICh2ZWN0b3IsIExpc3BfTmF0aXZlX0NvbXBfVW5pdCk7Ci0g ICAgICBlYXNzZXJ0IChjdS0+aGFuZGxlKTsKLSAgICAgIGR5bmxpYl9jbG9zZSAoY3UtPmhhbmRs ZSk7CisgICAgICB1bmxvYWRfY29tcF91bml0IChjdSk7CiAgICAgfQogICBlbHNlIGlmIChOQVRJ VkVfQ09NUF9GTEFHCiAJICAgJiYgUFNFVURPVkVDVE9SX1RZUEVQICgmdmVjdG9yLT5oZWFkZXIs IFBWRUNfU1VCUikpCmRpZmYgLS1naXQgYS9zcmMvY29tcC5jIGIvc3JjL2NvbXAuYwppbmRleCBi NjhhZGYzMWQ2OGJkLi5jOWUwNjhiOTBhYTJjIDEwMDY0NAotLS0gYS9zcmMvY29tcC5jCisrKyBi L3NyYy9jb21wLmMKQEAgLTQ5MzYsNiArNDkzNiwyMCBAQCBsb2FkX2NvbXBfdW5pdCAoc3RydWN0 IExpc3BfTmF0aXZlX0NvbXBfVW5pdCAqY29tcF91LCBib29sIGxvYWRpbmdfZHVtcCwKICAgcmV0 dXJuIHJlczsKIH0KIAordm9pZAordW5sb2FkX2NvbXBfdW5pdCAoc3RydWN0IExpc3BfTmF0aXZl X0NvbXBfVW5pdCAqY3UpCit7CisgIGlmIChjdS0+aGFuZGxlID09IE5VTEwpCisgICAgcmV0dXJu OworCisgIExpc3BfT2JqZWN0ICpzYXZlZF9jdSA9IGR5bmxpYl9zeW0gKGN1LT5oYW5kbGUsIENP TVBfVU5JVF9TWU0pOworICBMaXNwX09iamVjdCB0aGlzX2N1OworICBYU0VUTkFUSVZFX0NPTVBf VU5JVCAodGhpc19jdSwgY3UpOworICBpZiAoRVEgKHRoaXNfY3UsICpzYXZlZF9jdSkpCisgICAg KnNhdmVkX2N1ID0gUW5pbDsKKyAgZHlubGliX2Nsb3NlIChjdS0+aGFuZGxlKTsKK30KKwogTGlz cF9PYmplY3QKIG5hdGl2ZV9mdW5jdGlvbl9kb2MgKExpc3BfT2JqZWN0IGZ1bmN0aW9uKQogewpk aWZmIC0tZ2l0IGEvc3JjL2NvbXAuaCBiL3NyYy9jb21wLmgKaW5kZXggZjdkMTdmMzk4Yzc1ZC4u ZDAxYmMxNzU2NWQ3ZCAxMDA2NDQKLS0tIGEvc3JjL2NvbXAuaAorKysgYi9zcmMvY29tcC5oCkBA IC03OCw2ICs3OCw4IEBAIFhOQVRJVkVfQ09NUF9VTklUIChMaXNwX09iamVjdCBhKQogZXh0ZXJu IExpc3BfT2JqZWN0IGxvYWRfY29tcF91bml0IChzdHJ1Y3QgTGlzcF9OYXRpdmVfQ29tcF9Vbml0 ICpjb21wX3UsCiAJCQkJICAgYm9vbCBsb2FkaW5nX2R1bXAsIGJvb2wgbGF0ZV9sb2FkKTsKIAor ZXh0ZXJuIHZvaWQgdW5sb2FkX2NvbXBfdW5pdCAoc3RydWN0IExpc3BfTmF0aXZlX0NvbXBfVW5p dCAqKTsKKwogZXh0ZXJuIExpc3BfT2JqZWN0IG5hdGl2ZV9mdW5jdGlvbl9kb2MgKExpc3BfT2Jq ZWN0IGZ1bmN0aW9uKTsKIAogZXh0ZXJuIHZvaWQgc3ltc19vZl9jb21wICh2b2lkKTsKLS0gCjIu MzAuMQoK --0000000000001d280905bd00d58d--